c# - CompositeWPF : EventAggregator - when to use?

我一直在寻找Composite Application Library，这很棒，但是我在决定何时使用EventAggregator ...或更确切地说-什么时候不使用它时遇到了麻烦。

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

我已经决定将其用于繁重的工作任务，该任务应在后台线程上运行。在这种情况下，EventAggregator提供了后台的线程编码，因此我不必为此担心。除此之外，我喜欢这种方法提供的去耦。

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

最佳答案

这是一个很好的问题。在Composite WPF(Prism)中，有3种可能的方法可以在应用程序的各个部分之间进行通信。一种方法是使用命令，该命令仅用于将UI触发的 Action 传递给实现该 Action 的实际代码。另一种方法是使用共享服务，其中多个部分持有对同一服务(Singleton)的引用，并且它们以经典方式处理该服务上的各种事件。如前所述，对于断开和异步通信，最好的方法是使用Event Aggregator(与Martin Fowler的模式非常相似)。

现在，何时不使用它:

需要在模块之间进行通信时使用它。 (例如，任何其他模块创建任务时，都需要通知任务模块)。

当您有多个可能的接收者或同一事件的来源时，请使用它。例如，您有一个对象列表，并且想要在保存或创建该类型的对象时刷新它。您无需订阅对所有打开的编辑/创建屏幕的引用，只需订阅此特定事件即可。

仅当您必须在Model View Presenter区域中订阅正常事件时才使用它。例如，如果您的演示者监听模型中的更改(例如，模型实现了INotifyPropertyChanged)，而您的演示者需要对此类更改使用react，则最好由演示者直接处理模型的PropertyChanged事件，而不是将此类事件转移到模型中。事件聚合器。因此，如果发送方和接收方都在同一单元中，则无需将此类事件“广播”到整个应用程序。

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