11

我一直在研究Composite Application Library，它很棒，但我无法决定何时使用 EventAggregator ......或者更确切地说 - 何时不使用它。

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

我已经决定将它用于与繁重的工作任务进行通信，该任务应该在后台线程上运行。在这种情况下，EventAggregator 在幕后提供线程编组，所以我不必太担心。除此之外，我喜欢这种方法提供的解耦。

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

4

1 回答 1

21

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

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

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

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

于 2009-02-18T06:35:29.417 回答