c# - EventAggregator 仅适用于 MVVM 中的 ViewModels 吗？

Question

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

我认为事件聚合器确实是个好主意。但转念一想，事件聚合器是否仅供 ViewModel 使用？模型可以在事件聚合器中发布和订阅事件吗？

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

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

编辑:

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

首先，所以使用 DI，我的 ViewModel 包装了模型。然后我的 ViewModel 可以与我的模型通信。然而，反之则不然。因此，如果我的模型自身或外部发生了一些变化，它需要一种方法来通知它的 ViewModel。

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

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

Answer 1

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

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

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

1. 它增加了一个层次或间接，使代码更难阅读。根据您拥有的开发工具，映射事件发布者和订阅者可能会很麻烦。
2. 它需要大量的“脚手架”代码才能使其工作。如果它被过度使用，这可能会成为一种负担(您需要跟踪什么事件做了什么，等等)。
3. 如果是针对简单的数据请求，用事件聚合器事件替换服务方法在大多数情况下是行不通的。每个方法调用需要 2 个事件(一个请求和一个响应事件)。您还必须小心发送错误的 View 模型数据:如果 View 模型 A 发送数据请求并且 View 模型 A 和 B 收到响应，那么您必须能够让 View 模型 B 过滤掉响应。<

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