EventAggregator vs CompositeCommand

Question

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

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

在交叉模块通信方面，特别是何时使用EventAggregation而不是复合命令，这一点不太清楚。

实际效果是相同的，例如。

• 您发布了一个事件 - ＆gt;所有订阅者都收到通知并执行响应代码
• 您执行复合命令 - ＆gt;所有已注册的命令都会被执行，并附带其附加的代码

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

我很难看到使用方法的实际差异，虽然我知道两者的实现（在引擎盖下）是非常不同的。

我们应该考虑它的实际含义 - 事件？是什么事情发生（事件发生）？用户没有像“完成网页请求”那样直接请求的东西？

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

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

所以我希望参与/使用棱镜的人可以帮助揭示这一点。

Answer 1

这两者之间存在两个主要差异。

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

希望这有助于解释这些差异。说什么时候使用每个都比较困难，但通常我会使用经验法则如果是用户交互引发事件，则使用命令执行其他操作，使用EventAggregator 。

希望这有帮助。

Answer 2

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

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