只是做一些快速的尖峰，可能使用消息传递系统处理一个很好地解耦的工作流系统中的文件。
人们发现使用上述每个框架的优点和缺点是什么？使用这些与使用WCF绑定和/或非MSMQ解决方案的手动MSMQ系统有什么好处？
答案 0 :(得分：71)
我建议远离手动解决方案，因为有一些有些困难的东西需要得到正确的解决 - 比如如何处理事务，例外如何导致回滚，如何无休止地停止回滚（毒药）消息），如何与长期运行的工作流程集成，以便状态管理边界排队等等。
您可能需要某种持久/事务性消息传递基础结构，因此不使用MSMQ，您将在Microsoft平台上使用Service Broker，或者使用ActiveMQ等其他替代方案。 MSMQ的好处是已经安装在所有Windows机器上，而不是Service Broker，而不是。
在NServiceBus，Mass Transit和Rhino Service Bus之间进行选择 - 这个Stackoverflow答案comparing NServiceBus to MassTransit将是一个很好的起点..
在我们的3.1版本中，我们将介绍NSB Studio - 一组Visual Studio集成建模工具，使您能够在更高的抽象级别对系统进行建模，并为您完成NServiceBus的大部分配置和初始化自动。我会说这真的有助于提升NServiceBus的规模。
希望有所帮助。
免责声明：我是NServiceBus的作者。
答案 1 :(得分：51)
NServiceBus 是一个很好的产品，但要注意许可问题。根据作者的意愿，它倾向于改变许可政策。请查看old license information.
上的示例可能会发生在项目开发过程中你会发现你需要为NServiceBus付出很多钱。
免费版也有性能限制。
MassTransit 是完全免费的开源软件，它没有任何限制，并且在Apache 2.0许可下。
我没有使用 Rhino Service Bus 。
答案 2 :(得分：25)
Rhino vs NServicebus状态的更新：
http://www.infoq.com/news/2012/04/nservicebus3-0
InfoQ to Ayende： 您之前已经为.NET编写过服务总线 你自己，就是Rhino Service Bus。应该是Rhino Service的用户 巴士现在重新考虑并转移到NServiceBus？
Ayende：我在2008年左右建立了Rhino Service Bus。我主要是建立它 因为我对其他服务巴士的状态不满意 时间。在构建我时，我有不同的顾虑和方向 服务巴士，但那是4年前。在那个时候，我认为 NServiceBus在成为易于使用的产品方面取得了长足的进步 并有一个更好的开箱即用的开发故事。如果我是 今天从服务巴士开始，我强烈怀疑我会这样做 建立自己的。
答案 3 :(得分：9)
任何基于MSMQ的潜在con是对最大邮件大小的限制。 IIRC大约是4MB，如果您处理大文件并将文件内容存储在消息中，您可能很容易遇到这种情况。