使用WCF而不是MassTransit或手写MSMQ客户端等框架有什么好处？

Question

我正在考虑使用MSMQ作为在即将到来的项目中执行异步执行的解决方案。我想知道使用WCF和MassTransit等框架之间的区别，甚至是手写的MSMQ客户端来放置/读取MSMQ上的任务。

基本上，应用程序将是通过服务层（无论是WCF还是普通的Web服务）读取/写入数据的几个网站（内部通过LAN或通过Internet外部）。然后，此服务层将执行以下两项操作之一：1。将数据写入数据库2.和/或通过在队列中放置消息来触发后台进程。 3.显然它也可以从数据库中检索数据。队列另一端的小代理（Windows服务）将监视队列并根据任务命令执行。

与RPC或分布式执行等相比，此体系结构非常容易扩展（添加更多队列和代理）并且易于实现。并且代理处理不需要是实时的。代理和服务层是独立的应用程序，除了它们共享公共域对象和存储库等。

你怎么看？欢迎对上述要求的架构建议。谢谢！

Answer 1

WCF在MSMQ上添加了一个抽象。实际上，一旦定义了兼容的合同（操作必须是OneWay），您就可以透明地在配置中切换出MSMQ。 （例如，您可以切换到正常的HttpWS或NetTcp绑定。）

您应该评估其他WCF的好处，例如安全性等，以了解这些好处如何适合您的需求。同样，他们应该合理地透明你在下面使用MSMQ的事实。例如，添加SOAP安全性等应该“正常工作”，与使用MSMQ无关。

（虽然，IIRC，您仍然需要在使用MSMQ的每台计算机上登录桌面，使用将使用MSMQ的服务帐户，以在计算机本地配置文件中生成证书。然后，它在IIS6中运行效果不佳，因为没有加载用户配置文件。一般来说真的很痛苦，但与WCF没有任何关系。）

---

除此之外：

你看过SQL Server Service Broker吗？在使用MSMQ + WCF和SSSB之后，我认为SSSB 更容易配置和管理。 SSSB可以在任何SQL客户端上使用T-SQL命令（我在Mono上使用它，在Linux上使用事务）。它也会给你交易发送/接收，甚至远程（我认为MSMQ 4现在允许这样）。消息排队真的需要很多痛苦，如果你已经在使用SQL Server ......

SSSB经常被忽视，因为SQL Management Studio没有GUI设计器，但它并不难，而且是一个很好的选择。一个缺点是，如果您想要本地发送功能（即网络中断时的队列消息），您将需要运行本地SQL Express实例。

Answer 2

您的架构似乎合理而且合理。但是，您应该考虑在手动编码的MSMQ类上使用WCF net MSMQ传输。 WCF将这个通用功能包装到一个很好的编程模型中。另外我相信wcf使用的协议与基本的System.Messaging相比有一些改进

Answer 3

看看普通MSMQ的增值：

http://readthedocs.org/docs/masstransit/en/latest/overview/valueadd.html

总之，您可以通过MassTransit在API中清楚地看到许多消息传递概念;在某种程度上，如果您手工编码或使用WCF，您将无法获得。