在 Prism 中使用 EventAggregator 的最佳实践是什么？目前我有几个模块是松散耦合且独立工作的。这些模块使用 EventAggregator 与其他模块通信。随着应用程序的增长，我对如何记录我的代码感到困惑。可能有许多模块发布 Events 和许多其他订阅它，因为 Brian 说他们都不知道其他人到底在做什么。创建新模块时，如何确保它们订阅了某些 XYZ 事件而不破坏松散耦合结构？
如何使用 EventAggregator 直观地表示模块(某种图表)？
最佳答案
您的帖子中有很多问题可以回答“这取决于您的应用程序”，但我会尝试回答其中的一些问题。
我在 EventAggregator 中最常看到的一件事是滥用。许多人以一种使发布者和订阅者相互依赖的方式使用 EventAggregator。这给我带来了我的第一点建议:
永远不要假设某个事件有任何订阅者。
EventAggregator 可用于发布其他 View 可能感兴趣的事件。例如，在我们的应用程序中，我们允许用户更改某人的姓名。此名称可能会显示在应用程序中已打开的其他 View 上(我们有一个选项卡式 UI)。我们的用例是我们希望在名称更改时更新这些 UI，因此我们发布了一个“UserDataChanged”事件，以便打开的 View 可以适本地订阅和刷新其数据，但是如果没有打开的 View 对此数据感兴趣，没有通知订阅者。
在适当的情况下优先使用 .NET 事件而不是 EventAggregator 事件
我经常看到的另一个错误是使用 EventAggregator 实现的业务流程，其中数据被发送到中央方，然后该方回复，全部使用 EventAggregator。这会导致您可能想要避免的一些副作用。
我经常看到的一个变化是从父 View 到 subview 的通信，反之亦然。类似于“TreeItemChecked”或“ListViewItemSelected”。在这种情况下，将使用传统的 .NET 事件，但作者决定如果他们有锤子 (EventAggregator)，那么一切 (事件) 看起来都像钉子。
您询问了 对 EventAggregator 建模的问题，我会这样说:EventAggregator 的特殊之处在于它允许解耦并且不会创建对事件的强引用(避免内存泄漏等)。除此之外， 它实际上只是 Observer Pattern 的一个非常微小的变化。但是，您对 Observers 建模是在您尝试创建的任何类型的图表中对 EventAggregator 建模的方式。
至于你关于 确保某个模块或另一个模块订阅事件 的问题: 你没有 。如果需要确保有订阅者，则不应使用 EventAggregator。在这些情况下，我会推荐在您的应用程序中运行的服务，模块可以从您的容器中获取并使用或其他类似的东西。
关于您的模块要记住的一点是，您应该能够完全删除一个，而其余的应用程序功能正常。如果不是这种情况，你要么有一个模块依赖(最好避免，但可以理解)，或者依赖模块应该合并为一个。
关于prism - 如何设计 Prism EventAggregator？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1705658/