EventAggregator 与 CompositeCommand
我按照自己的方式完成了 Prism 指南，并认为我掌握了他们的大部分通信工具。
命令非常简单，因此很明显，DelegateCommand 将仅用于连接视图与其模型。
当涉及到跨模块通信时，特别是何时使用 EventAggregation 而不是 Composite Commands 时，还不太清楚。
实际效果是一样的，例如
- 你发布了一个事件->所有订阅者都会收到通知并执行代码作为响应
- 您执行复合命令 ->所有注册的命令都会被执行，并且它们附加的代码
都按照“即发即忘”的方式工作，也就是说，它们在触发事件/执行命令后不关心订阅者的任何响应。
尽管我知道两者的实现（在幕后）非常不同，但我很难看到使用上的实际差异。
那么我们是否应该考虑一下它的实际含义——事件？是指某事发生时（某事件发生）吗？用户没有直接请求的东西，例如“网络请求已完成”？
还有命令？这是否意味着用户单击了某些内容，从而向我们的应用程序发出了命令，直接请求服务？
是这样吗？或者是否有其他方法来确定何时使用其中一种通信工具而不是另一种。该指南虽然是我读过的最好的文档之一，但没有给出具体的解释。
因此，我希望参与/使用 Prism 的人们能够帮助阐明这一点。
I worked my way through the Prism guidance and think I got a grasp of most of their communication vehicles.
Commanding is very straightforward, so it is clear that the DelegateCommand will be used just to connect the View with its Model.
It is somewhat less clear, when it comes to cross Module Communication, specifically when to use EventAggregation over Composite Commands.
The practical effect is the same e.g.
- You publish an event -> all subscribers receive notice and execute code in response
- You execute a composite command -> all registered commands get executed and with it their attached code
Both work along the lines of "fire and forget", that is they don't care about any responses from their subscribers after firing the event/executing the commands.
I have trouble seeing a practical difference in usage although I understand that the implementation of both (under the hood) is very different.
So should we think of what it actually means - Event? Is that when something happens (an event occurs)? Something the user did not directly request like a "web request completed"?
And Command? Does that mean a user clicked something and thus issued a command to our application, requesting a service directly?
Is that it? Or are there other ways to determine when to use one of these communication vehicles over the other. The guidance, although one of the best documentations I read, gives no specific explanation.
So I hope people involved in/using Prism can help in shedding some light on this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这两者之间有两个主要区别。
可以说它是否有效
通过调用来执行
Command.RaiseCanExecuteChanged() 和
有其 CanExecute 委托
返回假。如果您考虑
“全部保存”的情况
CompositeCommand 合成多个
“保存”命令，但其中一个
命令说不能
执行后，“全部保存”按钮将
自动禁用（很好！）。
模式和命令是
命令模式。虽然
CompositeCommands 没有明确
一个 UI 模式，它是隐式的
（通常它们连接到
输入操作，如按钮单击）。
EventAggregator 不是这样的 -
应用程序的任何部分
有效地引发 EventAggregator
事件：后台进程，
ViewModels 等。它是
消息传递的中介途径
在您的应用程序中提供支持
对于诸如过滤之类的事情，
后台线程执行等。
希望这有助于解释差异。很难说出何时使用每种方法，但通常我使用的经验法则是，如果是用户交互引发事件，则使用命令执行其他操作，则使用 EventAggregator。
希望这有帮助。
There are two primary differences between these two.
can say whether or not it is valid
for execution by calling
Command.RaiseCanExecuteChanged() and
having its CanExecute delegate
return false. If you consider the
case of a "Save All"
CompositeCommand compositing several
"Save" commands, but one of the
commands saying that it can't
execute, the Save All button will
automatically disable (nice!).
pattern and Commands are a
Commanding pattern. Although
CompositeCommands are not explicitly
a UI pattern, it is implicitly so
(generally they are hooked up to an
input action, like a Button click).
EventAggregator is not this way -
any part of the application
effectively raise an EventAggregator
event: background processes,
ViewModels, etc. It is a
brokered avenue for messaging
across your application with support
for things like filtering,
background thread execution, etc.
Hope this helps explain the differences. It's more difficult to say when to use each, but generally I use the rule of thumb that if it's user interaction that raises the event, use a command for anything else, use EventAggregator.
Hope this helps.
此外，还有一个更重要的区别：在当前的实现中，来自 EventAggregator 的事件是异步的，而 CompositeCommand 是同步的。
如果您想实现类似“通知事件 X 发生；执行依赖于事件 X 的事件处理程序来执行的操作”之类的操作，您要么必须执行诸如 Application.DoEvents() 之类的操作，要么使用 CompositeCommands。
Additionally, there is one more important difference: With the current implementation, an event from the EventAggregator is asynchronous, while the CompositeCommand is synchronous.
If you want to implement something like "notify that event X happened; do something that relies on the event handlers for event X to have executed", you either have to do something like Application.DoEvents() or use CompositeCommands.