C# EventAggregator是否仅适用于MVVM中的ViewModels？

我了解到MVVM设计中实现的事件聚合器模式有助于解耦ViewModels之间的通信

我认为事件聚合器确实是个好主意。但再想想，事件聚合器是否仅由ViewModels使用？模型可以发布到事件聚合器中的事件并从中订阅吗

也许通过这种方式，ViewModel和Model之间的数据更改可以通过EventAggregator进行关联。这可能会允许一个ViewModel从多个模型检索信息，而不需要ViewModel存储对所有模型的引用

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

编辑：

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

首先，使用DI，我的ViewModel包装模型。然后，我的ViewModel可以与我的模型通信。然而，情况并非如此。因此，如果我的模型本身或外部有一些更改，它需要一种通知其ViewModel的方法

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

---

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

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

在viewmodel级别，以便viewmodels可以发送通知，其他感兴趣的对象可以接收这些通知，或者接收有关它们感兴趣的事件的消息

在服务（或模型）级别，模型将数据流发送出去。取而代之的是viewmodel通过方法调用请求数据，它只接收“新数据”事件

如果有多个服务向viewmodel提供相同的数据，它可以将数据聚合到单个流中

您有一个系统范围的事件（系统关闭），它让您的viewmodels和/或服务知道它们必须优雅地终止。这让他们有时间关机

值得记住的是，使用事件聚合器有一些缺点：

它添加了一个级别或间接寻址，使代码更难阅读。映射事件发布者和订阅者可能会造成麻烦，具体取决于您使用的开发工具

它需要大量的“脚手架”代码才能工作。如果过度使用，这可能会成为一种负担（您需要跟踪什么事件做什么，等等）

如果是为了简单的数据请求，用事件agregator事件替换服务方法在很大程度上是行不通的。每个方法调用需要2个事件（一个请求和一个响应事件）。您还必须小心发送错误的viewmodel数据：如果viewmodel A发送数据请求，并且viewmodel A和B收到了它的响应，那么您必须能够让viewmodel B过滤掉响应

---

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

我迫不及待的回答是，这似乎不对。因为您可以通过一个接口在Model和ViewModel之间使用依赖项注入。所以你不必手动管理订阅者/发布者…@Johnny是的，我可以通过接口使用DI。但是我看到了两个可能的问题：首先，对于DI，我的ViewModel包装了模型。然后，我的ViewModel可以与我的模型通信。然而，情况并非如此。因此，如果我的模型本身或外部有一些更改，它需要一种通知其ViewModel的方法。其次，除了ViewModels必须与其他ViewModels通信之外，在我看来，模型与其他模型的通信量与ViewModels一样大，甚至更多。这些导致了我认为我可以把所有东西都链接到EventAggregator上。好的，实际上我看到了3个可能的问题，这就引出了这个问题。我用这个问题的动机更新了我的问题。再想一想，我倾向于同意你//编辑：我希望这方面有资格的人能回答你的问题。