EventAggregator仅适用于MVVM中的ViewModels吗？

Question

我读到有关在MVVM设计中实现的Event Aggregator模式可以帮助解耦ViewModel之间的通信.

我认为Event Aggregator真是个好主意.但是,第二个想法是,事件聚合器是否仅由ViewModels使用？模型可以发布到事件聚合器中的事件并从中订阅吗？

也许,通过这个,ViewModel和Model之间的数据变化可以通过EventAggregator进行关联.这可能允许一个ViewModel从多个模型中检索信息,而不需要ViewModel来存储对所有模型的引用.

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

编辑:

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

首先,使用DI,我的ViewModel包装了Model.然后我的ViewModel可以与我的模型通信.但是,不是相反.因此,如果我的模型本身或外部都有一些更改,则需要一种方法来通知其ViewModel.

其次,除了ViewModels必须与其他ViewModel进行通信之外,在我看来,模型必须与ViewModel一样多,甚至更多地与其他模型进行通信.这些导致我认为我可以将所有内容链接到EventAggregator.

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

Answer 1

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

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

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

1. 它增加了一个级别或间接,使代码更难阅读.映射事件发布者和订阅者可能会产生麻烦,具体取决于您拥有的开发工具.
2. 它需要一定量的"脚手架"代码才能使其正常工作.如果过度使用(您需要跟踪哪些事件做什么等),这可能会成为负担.
3. 如果是简单的数据请求,那么在大多数情况下用事件agregator事件替换服务方法是行不通的.每个方法调用需要2个事件(请求和响应事件).您还必须小心发送错误的viewmodel数据:如果viewmodel A发送数据请求并且它的响应由viewmodel A和B接收,那么您必须能够让viewmodel B过滤掉响应.

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