CompositeWPF：EventAggregator - 何时使用？

Question

我一直在研究复合应用程序库，它很棒，但我无法决定何时使用 EventAggregator...或者更确切地说 - 何时不使用它。

看看 StockTraderRI 的例子，我更加困惑了。 他们在某些情况下使用 EventAggregator，在其他情况下使用“经典”事件（例如在 IAccountPositionService 接口中）。

我已经决定使用它来与繁重的工作任务进行通信，该任务应该在后台线程上运行。 在本例中，EventAggregator 在幕后提供线程编组，因此我不必对此太担心。 除此之外，我喜欢这种方法提供的解耦。

所以我的问题是：当我开始在应用程序中使用 EventAggregator 时，为什么不将其用于所有自定义事件？

Answer 1

这是一个很好的问题。 在 Composite WPF (Prism) 中，有 3 种可能的方式在应用程序的各个部分之间进行通信。 一种方法是使用 Commanding，它仅用于将 UI 触发的操作传递到实现该操作的实际代码。 另一种方法是使用共享服务，其中多个部分保存对同一服务（单例）的引用，并以经典方式处理该服务上的各种事件。 对于断开连接和异步通信，正如您已经说过的，最好的方法是使用事件聚合器（它严格遵循 Martin Fowler 的模式）。

现在，何时使用和不使用它：

1. 当您需要在模块之间进行通信时使用它。 （例如，当任何其他模块创建任务时，任务模块需要得到通知）。
2. 当同一事件有多个可能的接收者或源时，请使用它。 例如，您有一个对象列表，并且希望在保存或创建该类型的对象时刷新它。 您只需订阅此特定事件，而不是保留对所有打开的编辑/创建屏幕的引用。
3. 当您只需订阅模型视图呈现器区域中的普通事件时，请勿使用它。 例如，如果您的 Presenter 监听 Model 中的更改（例如 Model 实现了 INotifyPropertyChanged），并且您的 Presenter 需要对此类更改做出反应，那么您的 Presenter 最好直接处理 Model 的 PropertyChanged 事件，而不是通过事件聚合器。 因此，如果发送者和接收者位于同一单元，则无需向整个应用程序“广播”此类事件。

我希望这回答了你的问题。