为什么用Handle（）分隔类CommandHandler而不是Command本身的处理方法

我有一部分使用S＃arp Architecture实施的CQRS模式，如下所示：

public class MyCommand
{
    public CustomerId { get; set; }

    // some other fields
}

public class MyCommandHandler<MyCommand> : ICommandHandler<MyCommand, CommandResult>
{
    Handle(MyCommand command)
    {
        // some code for saving Customer entity

        return CommandResult.Success;
    }
}

我想知道为什么不只Command包含数据和处理方法的类？这是一种可测试性的好处，您需要与命令属性分开测试命令处理逻辑吗？还是某些频繁的业务需求，您需要由不同的实现来处理一个命令ICommandHandler<MyCommand, CommandResult>？

有趣的是，这个问题使我想起了我与一位工程师就我正在研究的通信库进行的完全相同的对话。

除了命令之外，我还有Request类，然后有RequestHandlers。设计非常像您所描述的。我认为您感到困惑的部分原因是您看到英文单词“ command”，然后立即想到“ verb，action ... etc”。

但是在此设计中，请将Command（或Request）视为一个字母。或者对于那些不知道邮政服务是什么的人，请考虑发送电子邮件。它只是内容，与应该如何操作内容脱钩。

你为什么要这样做？在大多数简单情况下，“命令模式”没有理由，您可以让此类直接执行工作。但是，如果您的动作/命令/请求必须经过一段距离，则按照设计中的方式进行去耦是有意义的。例如，跨越套接字或管道，或者在域和基础结构之间。或者，也许在您的体系结构中，您的命令需要持久化（例如，由于某些系统事件，命令处理程序一次只能执行1条命令，因此有200条命令到达，并且在关闭前40个进程之后）。在那种情况下，只有一个仅用于消息的类，将消息部分序列化为JSON / XML / binary / whatever就非常简单，然后将其传递到管道中，直到其命令处理程序准备好对其进行处理为止。

将Command与CommandHandler分离的另一个优点是，现在您可以选择并行继承层次结构。例如，所有命令都可以从支持序列化的基本命令类派生。也许您在20个命令处理程序中有4个具有很多相似性，现在您可以从Comed处理程序基类派生这些命令处理程序。如果要将数据和命令处理放在一个类中，则这种类型的关系很快就会失控。

解耦的另一个示例是，如果您的命令只需要很少的输入（例如2个整数和一个字符串），而其处理逻辑就足够复杂了，您希望将数据存储在中间成员变量中。如果将50个命令排队，则不想为所有中间存储分配内存，因此将Command与CommandHandler分开。现在，您排队了50个轻量级数据结构，并且处理命令的CommandHandler仅分配了一次（或者，如果您有N个处理程序，则分配了N次）更复杂的数据存储。

普通命令模式是将数据和行为放在单个类中。这种“命令/处理程序模式”略有不同。与普通模式相比，唯一的优势是不让您的命令依赖于框架的其他优势。例如，您的命令可能需要数据库访问权限，因此它必须具有某种数据库上下文或会话，这意味着它取决于框架。但是此命令可能是您域的一部分，因此您不希望它根据Dependency Inversion Principle依赖于框架。将输入和输出参数与行为分开，并让一些调度程序将其连接起来可以解决此问题。

另一方面，您将失去继承和命令组合的优势。我认为这是真正的力量。

此外，小nitpick。仅仅因为它的名称中包含Command并不会使它成为CQRS的一部分。那是更基本的东西。这种结构甚至可以同时用作命令和查询。