pub-sub事件的模式是 出版商不应该知道或关心 那里有订户， 也不应该关心什么 订阅者如果他们在那里（来自 Brian Noyes' blog）
在Prism中使用EventAggregator的最佳做法是什么？目前，我有几个松散耦合并独立工作的模块。这些模块使用EventAggregator与其他模块进行通信。随着应用程序的增长，我对如何记录代码感到困惑。可能有许多模块发布事件和许多其他订阅它的事情，因为布赖恩说他们都不知道其他人究竟做了什么。在创建新模块时，如何在不破坏松散耦合结构的情况下确保订阅某些XYZ事件？
如何使用EventAggregator直观地表示模块（某种图表）？
答案 0 :(得分：19)
你的帖子中有很多问题可以回答“这取决于你的应用程序”，但我会尝试回答其中一些问题。
我经常使用EventAggregator看到的一件事是滥用。许多人使用EventAggregator的方式使发布者和订阅者彼此依赖。这让我想到了我的第一点建议：
永远不要假设活动有任何子纤维。
EventAggregator对于发布可能感兴趣的其他视图的事件非常有用。例如，在我们的应用程序中，我们允许用户更改某人的姓名。此名称可能会显示在应用程序中已打开的其他视图上（我们有一个选项卡式UI）。我们的用例是我们希望在名称更改时更新这些UI，因此我们发布了一个“UserDataChanged”事件，以便打开视图可以适当地订阅和刷新其数据，但如果没有打开的视图对此数据感兴趣，没有订阅者收到通知。
在适当的事件中使用EventAggregator事件支持.NET事件
我经常看到的另一个错误是使用EventAggregator实现的业务流程，其中数据被发送到中央方，然后该方回复，全部使用EventAggregator。这会导致您可能想要避免的一些副作用。
我看到很多变化是从父视图到子视图的通信，反之亦然。像“TreeItemChecked”或“ListViewItemSelected”之类的东西。这是一种使用传统.NET事件的情况，但作者决定如果他们有锤子（EventAggregator），那么所有事件（事件）看起来都像钉子一样。
你问过建模EventAggregator ，我会这样说：EventAggregator只是特别之处在于它允许解耦并且不会创建对事件的强引用（避免内存泄漏等）。除此之外，它实际上只是Observer Pattern 的一个非常小的变化。但是，您正在建模Observers是如何在您尝试创建的任何类型的图表中为EventAggregator建模。
关于确保某个模块或其他模块订阅了某个活动的问题： 您没有 。如果您需要确保有订户，则不应使用EventAggregator。在这些情况下，我建议在您的应用程序中运行一个服务，模块可以从您的容器中获取并使用或其他类似的东西。
要记住模块的一点是，您应该能够完全删除一个和其他应用程序正常的功能。如果不是这种情况，您要么具有模块依赖性（最好避免，但可以理解），或者依赖模块应该合并为一个。