Command Dispatcher 和 Mediator 设计模式有什么区别？

Question

最近我被介绍到命令调度器模式，它可以帮助我们将命令与基于领域驱动设计方法和 CQRS 模式的项目中的命令处理程序分离。

无论如何，我把它与中介者设计模式混淆了。

Robert Harvey has already answered关于Command Dispatcher模式的问题如下：

Command Dispatcher 是一个将 Action-Request 与 适当的动作处理程序。它的目的是解耦 来自发送和接收对象的命令操作，以便 双方都不了解对方。

根据维基百科，The mediator pattern 被描述为：

使用中介者模式，对象之间的通信是 封装在中介对象中。对象不再通信 直接相互交流，而是通过 调解人。这减少了通信对象之间的依赖关系， 从而减少耦合。

因此，据我了解，他们都将命令与指挥官分开，这允许我们与调用者分离。

我在 Github 上看到了一些项目，它们使用命令调度器模式为请求的命令调用所需的处理程序，而其他项目则使用中介器模式来调度消息。 （例如，在大多数 DotNet 项目中，MediatR 库用于满足这一点。

但是，我想知道在我们基于 DDD 方法和 CQRS 模式的项目中使用一种模式与另一种模式有什么区别和好处？

Answer 1

中介者模式在其纯粹的概念上更加低级和通用。中介者模式没有定义您使用的通信类型或消息类型。在 Command Dispatcher 中，您处于上层（上下文和概念上），其中已经定义了通信和消息的类型。

您应该能够以 Mediator 模式（ergo with MediatR）为基础实现 Command Dispatcher 模式。

Answer 2

Command Dispatcher 和 Mediator 模式（以及 Event Aggregator 模式）的相似之处在于它们引入了一个 mediating 组件来解耦组件之间的直接通信。虽然每种模式都可以用于实现其他模式所针对的用例，但它们都是具体的模式，它们的原始目标问题以及它们适合每种需求的级别都不同。

命令调度程序模式主要是一种约定优于配置的方法，通常用于促进 UI 层调用应用程序层，使用离散类型来处理命令和查询，而不是更传统的应用程序服务设计。当将通常可能在课程粒度服务（例如 OrderService）中表示为离散组件（例如 CreateOrderCommand、GetOrderQuery 等）的查询和命令表示时，这可能会在 UI 级组件中产生相当多的噪音，例如ASP.Net MVC 控制器，其中构造函数可能需要注入一系列离散接口，每个用户请求通常只需要一个接口（例如控制器操作）。引入调度程序大大减少了实现组件（如 ASP.Net MVC 控制器）所需的代码量，因为唯一需要注入的依赖项是调度程序。虽然不一定是该模式的主要动机，但它还引入了统一应用其他模式（如管道和过滤器）的能力，并提供了一个可以在运行时确定命令处理程序实现的接缝。 MediatR 库实际上就是这种模式的一个实现。

中介者模式涉及创建中介组件，这些组件封装特定领域的编排逻辑，否则需要在组件之间进行耦合。也就是说，在这种情况下，中介组件不仅仅是一个愚蠢的调度程序（“嘿，有人知道如何处理 XYZRequest 吗？”），而是专门为遵循特定集合而构建的当给定操作发生时需要发生的操作，可能跨多个组件。 GoF Design Patterns 书中给出的示例是一个 UI 组件，它具有许多相互关联的元素，因此对一个组件的更改需要影响对许多其他组件的更改，反之亦然（例如，在文本字段中键入会导致对下拉列表的更改）和多个复选框和单选按钮，同时选择下拉效果中的条目会更改文本字段、复选框和单选按钮等中的内容）。使用所提供的解决方案，中介组件包含的逻辑可以准确了解哪些组件需要更新，以及其他每个组件何时更改。

因此，当您需要定制一个组件以促进许多其他组件如何交互时，将使用中介者模式，否则正常耦合会对可维护性产生负面影响，而命令调度程序模式只是用作一个哑功能路由器将调用者与被调用函数解耦。