何时应该使用事件处理程序而不是事件聚合器？

Question

我应该在什么情况下使用事件处理程序，而不是事件聚合器？

在我的代码中，我有两个由父ViewModel控制的ViewModel，我正在尝试决定是否应该仅使用事件处理程序在它们之间通信？还是使用事件聚合器？这将仅是简单的方法调用，我不需要在它们之间传递参数。

- Bob.

Answer 1

我看来，当你想要向整个应用程序发布事件，并且特别是当你不知道谁在监听时，EventAggregator通常是使用的重型武器。

在您的情况下，情况并非如此，您有2个视图模型希望进行通信，但它们都互相认识。所以没有真正的理由不能使用“事件”。

我只想提一下，如果您想使其耦合性更松散 - 为每个视图模型制作一个接口，以公开事件。这样，每个VM将使用“另一个VM”的接口而不是特定实例。

- Blachshma

---

你能用一个例子来解释最后一部分吗？ - Bob.

如果你使用某种**IoC，比如MEF*，则我的最后一部分会更有相关性。在这种情况下，你不知道谁实现*了特定的接口，只知道接口本身。所以在这个例子中，你会有两个接口IVM1和IVM2，每个接口都会有一个事件。VM1（它实现IVM1）并不知道VM2，它只知道IVM2，但由于事件是在IVM2中声明的，这就足够了。 - Blachshma

视图模型不必彼此知道。 - dthal

Answer 2

以下是一些有用信息（截至 5/2019）的链接： https://learn.microsoft.com/en-us/previous-versions/windows/apps/xx130639(v%3dwin.10)（Microsoft，Prism）

"Making key decisions" 部分描述了什么时候使用它。

.NET 中的事件实现了发布-订阅模式。发布者和订阅者的生命周期通过彼此的对象引用相互关联，并且订阅者类型必须具有对发布者类型的引用。

事件聚合是一种设计模式，可在不方便使用对象和类型引用进行链接的类之间进行通信。该机制允许发布者和订阅者进行通信，而无需相互引用。因此，应将 .NET 事件用于已具有对象引用关系的组件之间的通信（例如控件和包含它的页面），并使用事件聚合来进行松耦合组件之间的通信（例如应用程序中的两个独立页面视图模型）。有关更多信息，请参见 "Event aggregation"。

我粗略地认为这表明 C# 事件适用于层次结构（UI 监听业务逻辑）或父/子结构（仪器监听其包含的设备），而事件聚合则适用于兄弟结构（如兄弟 UI 面板或设备之间的通信）。

- dthal