簡體 English 中英

關於消息總線/命令調度程序模式的混淆

[英]Confusion about Message Bus / Command Dispatcher patterns

原文 2011-11-18 15:05:23 1 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實現？ 無論存在何種差異，您的經紀人都有責任使連接成為可能。