4

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

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

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

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

编辑：

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

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

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

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

4

1 回答 1

8

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

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

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

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

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

于 2012-10-26T10:18:24.483 回答