EventAggregator仅适用于MVVM中的ViewModels？ [英] Is EventAggregator only for ViewModels in MVVM?

问题描述

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

我以为事件聚合器真的是个好主意。但是在第二个想法中，事件聚合器是仅由ViewModels使用的？可以将模型发布到事件聚合器中的事件并从其中订阅？

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

如果我要这样做，那么导致整个架构凌乱，最终成为反模式？最好的做法是什么？

编辑：

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

第一个，所以用DI，我的ViewModel包装模型。我的ViewModel可以与我的模型进行通信。然而，不是相反。因此，如果我的模型有自己的或外部的一些变化，它需要一种方式通知它的ViewModel。

第二个除了ViewModels与其他ViewModels通信之外，在我看来，模型必须与其他模型进行通信，或者就像ViewModels一样。这些导致了我以为我可以把所有链接到EventAggregator的东西。

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

解决方案

有几个地方可以想要使用事件聚合器：

1. 在viewmodel级别，以便viewmodels可以发送可以被感兴趣的其他对象接收的通知或接收有关他们感兴趣的事件的消息。


2. 在模型发送数据流的服务（或模型）级别。而不是通过方法调用请求数据的视图模式，它将简单地接收新数据事件。


3. 如果您有多个服务向viewmodel提供相同的数据，则可以将数据聚合一个流。


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

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

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


2. 它需要大量的脚手架代码才能使其发挥作用。这可能会成为一个负担，如果它被过度使用（你需要跟踪什么事件做什么等等）。


3. 更换服务方式与事件集体活动大部分不'如果它是简单的数据请求，它将工作。每个方法调用需要2个事件（请求和响应事件）。您还必须小心发送错误的viewmodel数据：如果viewmodel A发送数据请求，并且其响应由viewmodel A和B接收，那么您必须能够使viewmodel B过滤出响应。 li>
   

一般来说，我不使用事件聚合器为服务通信提供服务（在我的主要工作项目中，我们有20个事件，只有1个其中服务于服务）。这是因为我的大部分服务电话是简单的一次性数据请求，而不是持续的更新流。

I read about the Event Aggregator pattern being implemented in an MVVM design can help to decouple the communication between the ViewModels.

I thought the Event Aggregator is really a good idea. But on a second thought, is the Event Aggregator only used by the ViewModels? Can Models publish to and subscribe from events in the Event Aggregator?

And through this, perhaps, data changes between the ViewModel and Model can then be related via the EventAggregator. This would then probably allow one ViewModel to retrieve information from multiple Models without having the ViewModel to store a reference to all the Models.

If I were to do this, would it cause the whole architecture to be messy and eventually become an anti-pattern? What would be the best practice?

Edit:

I thought I should explain a little on why I am asking this. I am seeing three possible problems:

First, so with DI, my ViewModel wraps the Model. My ViewModel can then communicate with my Model. However, not the other way round. So if my Model has some changes either on its own or externally, it needs a way to inform its ViewModel.

Second, apart from ViewModels having to communicate with other ViewModels, it seems to me that Models have to communicate with other Models as much, or even more, as ViewModels do. These lead to what I thought I could just get everything linked to the EventAggregator.

Third, I find that there are situations where a single ViewModel needs to pull information from multiple Models. But through a Dependency Injection via the ViewModel's constructor, it can only read from one Model.

解决方案

There are several places where you may want to use an event aggregator:

1. At the viewmodel level so that viewmodels can send out notifications that can be receivd by other objects that are interested or receive messages about events that they are interested in.
2. At the Service(or Model) level where the model is sending out a stream of data out. Instead of the viewmodel requesting data via a method call it would simply receive the "new data" events.
3. If you have multiple services providing the same data to a viewmodel it can aggregate the data into a single stream.
4. You've got a system-wide event (system shutdown) that lets your viewmodels and/or services know they've got to gracefully terminiate. This gives them time to shut down.

It's worth keeping in mind that there are drawbacks to using an event aggregator:

1. It adds a level or indirection, making the code harder to read. Mapping event publishers and subscribers can be a nuisance depending on what dev tools you have.
2. It requires an amount of "scaffolding" code to make it work. This can become a burden if it is over-used (you need to keep track of what events do what, etc).
3. Replacing service methods with event agregator events in the most part doesn't work if it's for simple data requests. You need 2 events per method call (a request and a response event). You also have to be careful about sending the wrong viewmodel data: if viewmodel A sends a request for data and it's response is received by viewmodel A and B then you've got to be able to have viewmodel B filter out the response.

Generally I don't use an event-aggregator to provide service to service communication (in my main work project we have 20 events, only 1 of which is service to service). This is because most of my service calls are simple one-off requests for data and not a continuous stream of updates.

这篇关于EventAggregator仅适用于MVVM中的ViewModels？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！