从另一个命令的Handle()方法中调用一个命令命令模式非常有趣的架构模型材料：容器将管理UnitOfWork的生命周期，我使用命令来执行数据库的特定功能。我的问题是，如果我有一个命令，比如AddNewCustomerCommand，它又调用另一个服务（即发送一条短信），从设计的角度来看，这是可以接受的吗？或者它应该处于更高级别，如果可以的话怎么做最好？示例代码如下：publicclassAddNewBusinessUnitHandler:ICommandHandler{privateIUnitOfWorkuow;私人ICommandHandler其他处理程序；AddNewBusinessUnitHandler(IUnitOfWorkuow,ICommandHandlerotherHandler){this.uow=uow;this.otherHandler=otherHandler;}publicBusinessCommandvoidHandle(=newBusinessUnit(){Name=command.BusinessUnitName,Address=command.BusinessUnitAddress};varotherCommand=newOtherServiceCommand(){welcomePostTo=command.BusinessUnitName};uow.BusinessUnitRepository.Add(businessUnit);这.otherHandler.Handle(otherCommand);}}它取决于（业务）命令的架构视图，但是用例和命令之间的一对一映射是自然的。在这种情况下，表示层应该（在单个用户操作期间，例如单击按钮）只执行创建命令并执行它。此外，它应该只执行一个命令，而不是更多。执行该用例所需的一切都应通过此命令完成。也就是说，发送文本消息、写入数据库、进行复杂计算、与Web服务通信以及处理业务需求所需的所有其他操作都应该在该命令的上下文中完成（或者可能排队等候）。不是之前，而是之后，因为它是一个以与表示无关的方式表达需求的命令。这并不意味着命令处理程序本身应该做所有这些。将大量逻辑移动到处理程序所依赖的其他服务是很自然的。所以我可以想象您的处理程序取决于ITextMessageSender接口。另一个讨论是命令处理程序是否应该依赖于其他依赖的命令处理程序。当您查看用例时，一个大用例不一定包含多个较小的子用例，因此从这个意义上讲并不奇怪。同样，命令和用例之间将存在一对一的映射。但是，请注意，相互依赖的嵌套命令处理程序的深度依赖关系图会使代码导航复杂化，因此请仔细查看。例如，注入ITextSessageSender而不是使用ICommandHandler可能更好。允许处理程序嵌套的另一个缺点是它会使基础设施的东西变得有点复杂。例如，当使用添加事务行为的装饰器包装命令处理程序时，您需要确保嵌套处理程序在与最外层处理程序相同的事务中运行。我今天碰巧帮助了我的客户。这并不难，但需要一点时间才能弄明白。对于死锁检测之类的事情也是如此，因为它也在事务边界上运行。此外，死锁检测是展示此命令/处理程序模式的强大功能的一个很好的示例，因为几乎所有其他架构风格都无法插入此行为。以本文中的DeadlockRetryCommandHandlerDecorator类为例。以上就是C#学习教程：从另一个命令调用命令的Handle()方法，分享所有内容。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文来自网络收集，不代表作品如涉及侵权，请点击右边联系管理员删除。如需转载请注明出处：
