EventAggregator仅适用于MVVM中的ViewModels吗？

Question

我读到有关在MVVM设计中实现的Event Aggregator模式可以帮助解耦ViewModel之间的通信。

我认为Event Aggregator真是个好主意。但是，第二个想法是，事件聚合器是否仅由ViewModels使用？模型是否可以在事件聚合器中发布和订阅事件？

通过这个，也许，ViewModel和Model之间的数据变化可以通过EventAggregator进行关联。这可能允许一个ViewModel从多个模型中检索信息，而无需ViewModel来存储对所有模型的引用。

如果我这样做，是否会导致整个架构变得混乱并最终变成反模式？什么是最佳做法？

修改

我想我应该解释一下我为什么要问这个问题。我看到了三个可能的问题：

首先，所以使用DI，我的ViewModel包装了Model。然后我的ViewModel可以与我的模型通信。但是，不是相反。因此，如果我的模型本身或外部都有一些更改，则需要一种方法来通知其ViewModel。

第二，除了ViewModels必须与其他ViewModel进行通信之外，在我看来，模型必须与ViewModel一样多，甚至更多地与其他模型进行通信。这些导致我认为我可以将所有内容链接到EventAggregator。

第三次，我发现在某些情况下，单个ViewModel需要从多个模型中提取信息。但是通过ViewModel构造函数的依赖注入，它只能从一个模型中读取。

Answer 1

有几个地方您可能想要使用事件聚合器：

1. 在viewmodel级别，以便viewmodel可以发送可以被其他感兴趣的对象接收的通知，或者接收有关他们感兴趣的事件的消息。
2. 在模型发送数据流的服务（或模型）级别。而不是通过方法调用请求数据的视图模型，它只是接收“新数据”事件。
3. 如果您有多个服务向viewmodel提供相同的数据，它可以将数据聚合到一个流中。
4. 您有一个系统范围的事件（系统关闭），让您的视图模型和/或服务知道他们必须优雅地终止。这让他们有时间关闭。

值得记住的是，使用事件聚合器存在缺陷：

1. 它增加了一个级别或间接，使代码更难阅读。映射事件发布者和订阅者可能会令人讨厌，具体取决于您拥有的开发工具。
2. 它需要一定量的“脚手架”代码才能使其正常工作。如果过度使用（你需要跟踪哪些事件做什么等等），这可能会成为负担。
3. 如果是简单的数据请求，则大多数情况下使用事件agregator事件替换服务方法不起作用。每个方法调用需要2个事件（请求和响应事件）。您还必须小心发送错误的viewmodel数据：如果viewmodel A发送数据请求并且它的响应由viewmodel A和B接收，那么您必须能够让viewmodel B过滤掉响应。

通常我不使用事件聚合器来为服务通信提供服务（在我的主要工作项目中，我们有20个事件，其中只有1个是服务服务）。这是因为我的大多数服务调用都是简单的一次性数据请求，而不是连续的更新流。