EventAggregator仅适用于MVVM中的ViewModels吗？
我读到有关在MVVM设计中实现的Event Aggregator模式可以帮助解耦ViewModel之间的通信。
我认为Event Aggregator真的是个好主意。 但是，第二个想法是，Event Aggregator仅由ViewModels使用吗？ 模型可以发布到事件聚合器中的事件并从中订阅吗？
也许，通过这种方式，ViewModel和Model之间的数据变化可以通过EventAggregator进行关联。 这可能允许一个ViewModel从多个模型中检索信息，而不需要ViewModel来存储对所有模型的引用。
如果我这样做，是否会导致整个架构变得混乱并最终变成反模式？ 什么是最佳做法？
编辑：
我想我应该解释一下为什么我这么问。 我看到三个可能的问题：
首先 ，使用DI，我的ViewModel包装了Model。 然后，我的ViewModel可以与我的模型通信。 但是，不是相反。 因此，如果我的模型本身或外部都有一些更改，则需要一种方法来通知其ViewModel。
其次 ，除了ViewModels必须与其他ViewModel进行通信之外，在我看来，模型必须与ViewModel一样多，甚至更多地与其他模型进行通信。 这些导致我认为我可以将所有内容链接到EventAggregator。
第三 ，我发现在某些情况下，单个ViewModel需要从多个模型中提取信息。 但是通过ViewModel构造函数的dependency injection，它只能从一个Model中读取。
有几个地方您可能想要使用事件聚合器：
- 在viewmodel级别，以便viewmodel可以发送可以被其他感兴趣的对象接收的通知，或者接收有关他们感兴趣的事件的消息。
- 在服务（或模型）级别，模型正在发送数据流。 而不是通过方法调用请求数据的视图模型，它将简单地接收“新数据”事件。
- 如果您有多个服务向viewmodel提供相同的数据，它可以将数据聚合到单个流中。
- 您有一个系统范围的事件（系统关闭），让您的视图模型和/或服务知道他们必须优雅地终止。 这让他们有时间关闭。
值得记住的是，使用事件聚合器有一些缺点：
- 它增加了一个级别或间接，使代码更难阅读。 映射事件发布者和订阅者可能会产生麻烦，具体取决于您拥有的开发工具。
- 它需要一定数量的“脚手架”代码才能使其正常工作。 如果过度使用（您需要跟踪哪些事件做什么等），这可能会成为负担。
- 如果是简单的数据请求，那么在大多数情况下用事件agregator事件替换服务方法是行不通的。 每个方法调用需要2个事件（请求和响应事件）。 您还必须小心发送错误的viewmodel数据：如果viewmodel A发送数据请求并且它的响应由viewmodel A和B接收，那么您必须能够让viewmodel B过滤掉响应。
通常我不使用事件聚合器来为服务通信提供服务（在我的主要工作项目中，我们有20个事件，其中只有1个是服务服务）。 这是因为我的大多数服务调用都是简单的一次性数据请求，而不是连续的更新流。