如何设计棱镜EventAggregator？

Question

发布子事件的模式是，发布者不应该知道或关心是否有订阅者，也不应该关心订阅者在那里做什么(来自布莱恩·诺伊斯的博客)。

在棱镜中使用EventAggregator的最佳实践是什么？目前，我有几个模块是松散耦合和独立工作。这些模块使用EventAggregator与其他模块通信。随着应用程序的增长，我对如何记录我的代码感到困惑。可能会有许多模块发布事件，还有许多其他模块订阅它，正如Brian所指出的那样，它们都不知道其他模块到底在做什么。在创建新模块时，如何确保它们在不破坏松散耦合结构的情况下订阅某些XYZ事件？

如何使用EventAggregator直观地表示模块(某种图表)？

Answer 1

你的帖子中有很多问题可以回答，“这取决于你的申请”，但我会尝试回答其中一些问题。

在EventAggregator中，我经常看到的一件事是滥用。许多人使用EventAggregator的方式使发行者和订阅者相互依赖。这使我想到我的第一点建议：

从不假定事件中有任何接班人。

EventAggregator对于发布其他视图可能感兴趣的事件非常有用。例如，在我们的应用程序中，我们允许用户更改某人的名称。此名称可能显示在应用程序中已打开的其他视图上(我们有一个选项卡式UI)。我们的用例是，我们希望在更改名称时更新这些UI，因此我们发布了一个"UserDataChanged“事件，以便打开的视图能够适当地订阅和刷新其数据，但是如果没有打开的视图对此数据感兴趣，则不会通知订阅者。

偏爱.NET事件而不是EventAggregator事件(如果适当的话)

我经常看到的另一个错误是使用EventAggregator实现的业务流程，其中数据被发送到一个中心方，然后该方回复，所有这些都使用EventAggregator。这会导致一些你可能想避免的副作用。

我经常看到的一个变化是从父视图到子视图的通信，反之亦然。类似于"TreeItemChecked“或"ListViewItemSelected”的东西。在这种情况下，将使用传统的.NET事件，但一位作者认为，如果他们有锤子(EventAggregator)，一切(事件)看起来就像钉子一样。

您询问了建模EventAggregator的情况，我想这样说: EventAggregator之所以特殊，只是因为它允许解耦，不创建对事件的强烈引用(避免内存泄漏等)。除此之外，实际上只是 观测器模式的一个非常微小的变化。然而，您正在建模观察者是如何在您想要创建的任何类型的图表中建模EventAggregator的。

关于的问题，确保某些模块订阅了事件：，而不是。如果您需要确保有订阅者，则不应该使用EventAggregator。在这些情况下，我建议在您的应用程序中运行一个模块可以从容器中获取的服务，并使用它或其他类似的东西。

关于您的模块，要记住的是，您应该能够正常地完全删除一个和其余的应用程序功能。如果不是这样的话，您要么有一个模块依赖(最好避免，但可以理解)，要么应该将依赖模块合并为一个模块。