EventAggregator vs CompositeCommand

Question

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

命令非常简单,因此很明显DelegateCommand仅用于将View与其模型连接起来.

当涉及交叉模块通信时,特别是何时使用EventAggregation而不是复合命令时,它有点不太清楚.

实际效果是相同的,例如

• 您发布事件 - >所有订阅者都会收到通知并执行响应代码
• 您执行复合命令 - >执行所有已注册的命令,并使用它们附加的代码

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

我很难看到使用中的实际差异,虽然我知道两者(引擎盖下)的实现是非常不同的.

那么我们应该想一想它的实际含义 - 事件？是什么事情发生(事件发生)？用户没有像"完成网页请求"那样直接请求的内容？

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

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

因此,我希望参与/使用棱镜的人可以帮助揭示这一点.

Answer 1

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

1. CanExecute for Commands.命令可以通过调用Command.RaiseCanExecuteChanged()并使其CanExecute委托返回false来判断它是否对执行有效.如果您考虑"全部保存"CompositeCommand合成多个"保存"命令的情况,但其中一个命令表明它无法执行,则全部保存按钮将自动禁用(很好!).
2. EventAggregator是一种消息传递模式,命令是一种命令模式.虽然CompositeCommands不是显式的UI模式,但它是隐式的(通常它们连接到输入操作,如Button单击).EventAggregator不是这种方式 - 应用程序的任何部分都有效地引发了一个EventAggregator事件:后台进程,ViewModels等.它是一个代理通过应用程序进行消息传递的途径,支持过滤,后台线程执行等.

希望这有助于解释差异.更难说何时使用每个,但通常我使用经验法则,如果它是引发事件的用户交互,则使用命令执行其他任何操作,使用EventAggregator.

希望这可以帮助.

Answer 2

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

如果你想实现类似"通知事件X发生的事情;做依赖于事件X的事件处理程序执行的事情",你要么必须做类似Application.DoEvents()的事情,要么使用CompositeCommands.