我刚刚在复习设计模式，并试图将我遇到的真实世界例子映射到设计模式上。
例如：代理模式 -> WCF
当我学习中介者模式时，企业服务总线（Enterprise Service Bus）浮现在我的脑海中，于是产生了以下问题。
1个回答
2
在中介者模式中，"对象之间的通信被封装在一个中介者对象中。"其目的是通过将通信路由细节留在中介者中来实现类的高内聚性。对象直接与中介者耦合，彼此之间松散耦合。
在企业服务总线架构中，"所有客户服务都以相同的方式与ESB通信：ESB将消息转换为正确的消息类型，并将消息发送到正确的生产者服务。" 对我来说，它似乎比GoF中介者更抽象，后者的示例往往与特定应用程序相关。例如，用户界面行为可能指定，当用户单击列表中的项目时，应将单击的项目复制到文本框中。这种行为逻辑非常特定于应用程序，但如果该逻辑分散在协作类之间（例如，项目列表和文本框各自管理一部分控件），则很难维护该逻辑。将该逻辑分散会使协作对象的内聚性降低。GoF中介者将这个应用程序逻辑集中起来，因此项目列表不知道文本框等内容。
我认为ESB提供路由服务，但它可能不太容易定制特定应用程序的行为。例如，实体仍然需要了解彼此以进行通信，但细节已被抽象化。行为是通过规则定义的。我可以将ESB视为通用中介者，但为了提供通用性而进行的抽象可能会使其比针对特定应用程序的GoF中介者更难理解（最终不够内聚）。
ESB更像是一种架构模式（通用服务），而中介者可以是非常特定于应用程序的模式。
在企业服务总线架构中，"所有客户服务都以相同的方式与ESB通信：ESB将消息转换为正确的消息类型，并将消息发送到正确的生产者服务。" 对我来说，它似乎比GoF中介者更抽象，后者的示例往往与特定应用程序相关。例如，用户界面行为可能指定，当用户单击列表中的项目时，应将单击的项目复制到文本框中。这种行为逻辑非常特定于应用程序，但如果该逻辑分散在协作类之间（例如，项目列表和文本框各自管理一部分控件），则很难维护该逻辑。将该逻辑分散会使协作对象的内聚性降低。GoF中介者将这个应用程序逻辑集中起来，因此项目列表不知道文本框等内容。
我认为ESB提供路由服务，但它可能不太容易定制特定应用程序的行为。例如，实体仍然需要了解彼此以进行通信，但细节已被抽象化。行为是通过规则定义的。我可以将ESB视为通用中介者，但为了提供通用性而进行的抽象可能会使其比针对特定应用程序的GoF中介者更难理解（最终不够内聚）。
ESB更像是一种架构模式（通用服务），而中介者可以是非常特定于应用程序的模式。
- Fuhrmanator
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接