我了解到在 MVVM 设计中实现的事件聚合器模式可以帮助解耦 ViewModel 之间的通信。
我认为事件聚合器确实是个好主意。但转念一想，事件聚合器仅由 ViewModel 使用吗？模型可以在事件聚合器中发布和订阅事件吗？
通过这种方式，ViewModel 和 Model 之间的数据更改也许可以通过 EventAggregator 关联起来。这可能允许一个 ViewModel 从多个模型检索信息，而无需 ViewModel 存储对所有模型的引用。
如果我这样做，是否会导致整个架构变得混乱并最终成为反模式？最好的做法是什么？
Edit:
我想我应该解释一下我为什么问这个。我看到三个可能的问题：
First，因此使用 DI，我的 ViewModel 包装了 Model。然后我的 ViewModel 可以与我的模型进行通信。然而，反之则不然。因此，如果我的模型本身或外部发生了一些更改，它需要一种方法来通知其 ViewModel。
Second除了 ViewModel 必须与其他 ViewModel 进行通信之外，在我看来，Model 还必须像 ViewModel 一样与其他 Model 进行通信，甚至更多。这些导致我认为我可以将所有内容链接到 EventAggregator。
Third，我发现有些情况下单个ViewModel需要从多个Model中提取信息。但通过 ViewModel 的构造函数进行依赖注入，它只能从一个模型中读取。
您可能希望在多个地方使用事件聚合器：
- 在视图模型级别，以便视图模型可以发出可由其他感兴趣的对象接收的通知，或接收有关他们感兴趣的事件的消息。
- 在服务（或模型）级别，模型发送数据流。视图模型不再通过方法调用请求数据，而是简单地接收“新数据”事件。
- 如果您有多个服务向视图模型提供相同的数据，它可以将数据聚合到单个流中。
- 您有一个系统范围的事件（系统关闭），让您的视图模型和/或服务知道它们必须优雅地终止。这给了他们关闭的时间。
值得记住的是，使用事件聚合器有一些缺点：
- 它增加了一个层次或间接性，使代码更难阅读。映射事件发布者和订阅者可能会很麻烦，具体取决于您拥有的开发工具。
- 它需要大量的“脚手架”代码才能使其工作。如果过度使用，这可能会成为一种负担（您需要跟踪哪些事件做了什么，等等）。
- 如果对于简单的数据请求，用事件聚合器事件替换服务方法在大多数情况下是行不通的。每个方法调用需要 2 个事件（请求事件和响应事件）。您还必须小心发送错误的视图模型数据：如果视图模型 A 发送数据请求并且视图模型 A 和 B 收到其响应，那么您必须能够让视图模型 B 过滤掉响应。
一般来说，我不使用事件聚合器来提供服务到服务的通信（在我的主要工作项目中，我们有 20 个事件，其中只有 1 个是服务到服务）。这是因为我的大多数服务调用都是简单的一次性数据请求，而不是连续的更新流。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
