我一直在寻找 Composite Application Library ，这很棒，但我无法决定何时使用 EventAggregator...或者更确切地说 - 何时不使用它。
再看看 StockTraderRI 的例子，我就更糊涂了。他们在某些情况下使用 EventAggregator，在其他情况下使用“经典”事件(例如在 IAccountPositionService 接口(interface)中)。
我已经决定用它来与繁重的工作任务通信，它应该在后台线程上运行。在这种情况下，EventAggregator 在幕后提供线程编码，因此我不必为此担心太多。除此之外，我喜欢这种方法提供的解耦。
所以我的问题是:当我开始在我的应用程序中使用 EventAggregator 时，为什么不将它用于所有 自定义事件？
最佳答案
这是个好问题。在 Composite WPF (Prism) 中，有 3 种可能的方法可以在您的应用程序的各个部分之间进行通信。一种方法是使用命令，它仅用于将 UI 触发的操作传递到实现该操作的实际代码。另一种方法是使用共享服务，其中多个部分持有对同一服务(单例)的引用，并且它们以经典方式处理该服务上的各种事件。对于断开连接和异步通信，正如您已经说过的，最好的方法是使用事件聚合器(它严格遵循 Martin Fowler 的模式)。
现在，何时使用和不使用它:
- 当您需要在模块之间进行通信时使用它。 (例如，当任何其他模块创建任务时，需要通知任务模块)。
- 当同一事件有多个可能的接收者或来源时使用它。例如，您有一个对象列表，并且希望在保存或创建该类型的对象时刷新它。您无需保留对所有打开的编辑/创建屏幕的引用，而只需订阅此特定事件。
- 如果您只需要订阅模型 View 展示器区域中的普通事件，请不要使用它。例如，如果您的 Presenter 监听 Model 中的更改(例如，Model 实现了 INotifyPropertyChanged)并且您的 Presenter 需要对此类更改使用react，那么您的 Presenter 最好直接处理 Model 的 PropertyChanged 事件，而不是通过事件聚合器。因此，如果发送方和接收方都在同一个单元中，则无需将此类事件“广播”到整个应用程序。
我希望这能回答您的问题。
关于c# - 复合WPF : EventAggregator - when to use?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/555889/