繁体 English 中英

关于消息总线/命令调度程序模式的混淆

[英]Confusion about Message Bus / Command Dispatcher patterns

原文 2011-11-18 15:05:23 4 2 design-patterns/ event-handling/ distributed-system/ message-bus

最近我一直在阅读很多有关分布式消息传递和相关模式的内容。 我使用了一些工具支持的例子，比如例如NServiceBus 。

许多这些模式都在互联网上描述。 我最近读到的其中一些是：

Message Broker： http ： //msdn.microsoft.com/en-us/library/ff648849.aspx
消息总线： http ： //msdn.microsoft.com/en-us/library/ms978583.aspx
SOA中的消息传递模式： http ： //msdn.microsoft.com/en-us/library/aa480027.aspx
Udi Dahan关于差异的帖子： http ： //www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences/

如果使用像NService bus这样的工具来做很多工作而不考虑基础设施问题，那么当我尝试实现基本的Message Bus和命令处理程序时，一些问题已经得到了解决。 事实上，当谈到这些模式时，我看不出它们之间存在很多差异。

我不会粘贴代码，因为它很长，但我发现了两篇博文，很好地描述了我想谈的实现的想法。

消息总线： http ： //brentedwards.net/2010/04/13/roll-your-own-simple-message-bus-event-aggregator/

这个想法很简单，消息总线跟踪订阅者并在他们感兴趣的情况下将消息发送给不同的订阅者。

命令处理程序： http ： //weblogs.asp.net/shijuvarghese/archive/2011/10/18/cqrs-commands-command-handlers-and-command-dispatcher.aspx

它与消息总线非常相似。 命令总线为给定的命令类型调用命令处理程序。

所以在这两种情况下都有相似之处。

使用一种模式比另一种模式有什么真正的差异和好处（我不是在谈论支持工具）。 我错过了什么？

第二个问题是。 没有支持工具，消息总线是否有价值？ 我不认为自己会为自己的所有权利提供支持。

对于一个冗长而令人困惑的问题我很抱歉，但请不要犹豫，询问更多细节。

2 个解决方案

哇，要给出比你链接的MSDN更彻底或更可信的答案是很难的，所以让我们更简洁。

消息总线与通信有关。 它甚至不要求传递通信是否是命令。 它也不关心有效载荷是什么。 它是“类型不可知的”。 消息总线的主要关注点是跟踪谁应该获得每个通信（pub / sub）。 这种模式的一个好处是，它将支持您尚未拥有规范的未来扩展。 您可以在路上添加新的消息类型，此模型将很乐意提供它。 消息总线更可能分布在应用程序之外，甚至可能在您的机器外部（例如，在10台服务器的集群之间分发）。

命令处理程序模型涉及将动作与命令的执行分开。 传统上（至少在我使用的语言中）命令与UI控件及其事件和UI线程紧密相关。 使用这个旧模型，在应用程序中定制或扩展可用命令的范围也很困难（比如使用扩展DLL）。 命令处理程序模型将UI和命令执行的这些问题分开。 您现在可以灵活地轻松添加更多命令处理程序并在没有UI事件的情况下执行命令（可单元测试 ）。 这样可以实现更清晰，更模块化和可测试的代码。 命令处理程序更有可能在内部成为应用程序的一部分。 命令集的任何扩展都可能会影响您的一个应用程序而不是多个应用程序。

消息/命令代理关注连接不兼容或设计不同的独立系统。 这是您希望一个应用程序与另一个应用程序交互并且没有一个或两个应用程序的源代码的用例。 因此，您创建了一个代理，该代理从一方接收信息，并在另一方提供此信息，同时考虑到这两个应用程序进行通信所需的任何转换。 MSDN上的示例是一个电子商务网站，可能需要与支付处理器，运输公司和会计系统进行通信。 您可能无法更改任何这些应用程序（包括电子商务系统）的源代码。 也许电子商务系统需要IExamplePaymentGateway接口，而您的支付提供商需要IDifferentPaymentAPI接口。 也许一个API用XML实现，另一个用JSON实现？ 无论存在何种差异，您的经纪人都有责任使连接成为可能。