Service 使用命令、事件或服务

在设计应用程序的后端时，通常需要从实际执行操作的系统中抽象出执行操作的系统

在和设计模式中有这方面的元素

---

举例来说：

• 新用户提交注册表
• 您的应用程序接收到该数据并弹出一条消息，说“嘿，我有一些新的用户数据，请对此做些什么”
• 侦听器/处理程序/服务获取数据并对其进行处理

（如果没有意义，请告诉我）

---

在我的申请中，我通常会：

• 激发一个新事件，侦听器设置为处理该事件。

  Event:：Fire（'user.new'，$data）

• 使用数据创建一个新命令，该命令绑定到CommandHandler

  newNewUserCommand（$data）

• 调用服务中的方法并传入数据

  UserService:：newUser（$data）

虽然它们几乎完全相同，但我只是想知道——在创建应用程序的体系结构时，如何决定使用哪一个呢

激发设置侦听器以处理的新事件 事件：：fire（'user.new'，$data）

事件模式意味着可能有许多处理程序订阅同一事件，并且这些处理程序与发送方断开连接。此外，事件处理程序通常不会将信息返回给发送方（因为实际上可能有许多处理程序，并且对于返回谁的信息存在混淆）

所以，这不是你的情况

使用绑定到CommandHandler的数据创建一个新命令 NewUserCommand（$data）

命令是执行某些操作的扩展方式。它们可以被调度、管道化、排队等。如果您不需要所有这些功能，为什么要使事情复杂化

在服务中调用方法并传入数据 UserService:：newUser（$data）

嗯，这是最适合你的情况，不是吗

虽然这些几乎完全相同，但我 我只是想知道-你怎么决定什么时候用哪一个 您正在创建应用程序的体系结构

简单。从许多解决方案中，仅选择以下解决方案：

• 隐喻上合适（不要使用事件，因为您的逻辑看起来不像事件）
• 最简单的（不要深入到编程理论和方法的深度。总是选择解决方案，这会降低项目开发的复杂性）

何时对事件使用命令

命令：当我有一些单独的操作时，这些操作几乎没有依赖项，必须从不同的应用程序部分调用。最类似的是一些编辑器命令，可以从工具栏和菜单访问

---

事件：当我有多个（至少在透视图中）依赖操作时，可以在执行其他操作之前/之后调用这些操作。例如，如果您有许多服务，则可以使用事件对它们执行缓存失效。服务，更改特定对象时发出“IChangedObject”事件。其他服务订阅此类事件并对其作出响应，从而使其缓存失效。

太好了，非常感谢您解释每个事件背后的想法。您能否举例说明何时使用命令或事件模式。了解其中的微妙之处对我有很大帮助。