EventAggregator vs CompositeCommand

Question

我通过 Prism 指导工作，并认为我掌握了他们的大多数通信工具。

命令非常简单，因此很明显，DelegateCommand 将仅用于将 View 与其 Model 连接起来。

关于跨模块通信，特别是何时使用 EventAggregation 而不是复合命令，这一点不太清楚。

实际效果是一样的例如

• 您发布了一个事件 -> 所有订阅者都会收到通知并执行代码作为响应
• 您执行复合命令 -> 所有已注册的命令都将被执行，并附带它们的代码

两者都按照“触发后忘记”的方式工作，即他们不关心触发事件/执行命令后订阅者的任何响应。

虽然我知道两者的实现（在后台）非常不同，但我很难看到实际的使用差异。

那么我们应该考虑一下它的实际含义——事件吗？那是当事情发生（事件发生）时吗？用户没有直接请求的东西，比如“网络请求已完成”？

指挥部呢？这是否意味着用户点击了某些东西，从而向我们的应用程序发出命令，直接请求服务？

是这样吗？或者是否有其他方法可以确定何时使用其中一种通信工具而不是另一种。该指南虽然是我读过的最好的文档之一，但没有给出具体解释。

所以我希望参与/使用 Prism 的人可以帮助阐明这一点。

Answer 1

这两者之间有两个主要区别。

1. 可以执行命令。一个命令 可以说是否有效 通过调用执行 Command.RaiseCanExecuteChanged() 和 有它的 CanExecute 委托 返回假。如果你考虑 “全部保存”的情况 CompositeCommand 合成几个 “保存”命令，但 一个 命令说它不能 执行，Save All 按钮将 自动禁用（太好了！）。
2. EventAggregator 是一个消息传递 模式和命令是一个 指挥模式。虽然 CompositeCommands 不是显式的 一个 UI 模式，它是隐含的 （通常他们连接到一个 输入动作，如按钮单击）。 EventAggregator 不是这样的—— 应用程序的任何部分 有效地引发一个 EventAggregator 事件：后台进程， ViewModels 等。它是一个 消息传递的中介途径 在您的应用程序中提供支持 对于过滤之类的事情， 后台线程执行等

希望这有助于解释这些差异。很难说何时使用每一个，但通常我使用的经验法则是如果是引发事件的用户交互，则对其他任何事情使用命令，使用 EventAggregator。

希望这会有所帮助。

Answer 2

此外，还有一个更重要的区别：在当前的实现中，来自 EventAggregator 的事件是异步的，而 CompositeCommand 是同步的。

如果你想实现类似“通知事件 X 发生；做一些依赖于事件 X 已执行的事件处理程序的事情”，你要么必须做类似 Application.DoEvents() 的事情，要么使用 CompositeCommands。