设计模式 – 命令CommandHandler与服务有什么区别?

前端之家收集整理的这篇文章主要介绍了设计模式 – 命令CommandHandler与服务有什么区别?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我一直在阅读关于使用Command对象来表示我们的域暴露的用例,以及Command Handler对象来处理这些命令.

例如:

> RegisterUserCommand
> RegisterUserCommandHandler

但是看起来和RegisterUserService完全相同,其中命令对象将表示registerUser()方法的参数.

当然,如果该方法参数太多,我将最终创建一个对象来包装它,该对象将与RegisterUserCommand相同.

那么为什么要有不同的模式代表同样的事情呢?服务广泛,不是命令(从我的经验);这里有什么区别我失踪了?总之,为什么要用一个而不是另一个?

解决方法

有命令给你的好的老命令模式的好处:

>你可以参数化对象,例如一个UI元素,具有执行的命令
>您可以存储命令并稍后执行.在队列或事务日志中
>您可以跟踪您执行的命令,为您实现撤消的基础

如果您的服务很大,每个都有很多复杂的方法(如果方法不复杂,您可能不应该使用DDD或CQRS),那么将每个方法移动到命令处理程序中可能会使应用程序更易于组合,更容易测试等等.毫无疑问,直接从大型服务重构的命令/命令处理程序的人常常将其视为后者模式的一个好处.但是您可以通过将大型服务分解成较小的服务(如您的示例中的特定服务所建议的)可以获得同样的好处,因此严格来说,服务和命令/命令处理程序之间没有区别.

猜你在找的HTML相关文章