prism - 如何设计 Prism 事件聚合器？

Question

Pattern of pub-sub events is that the publisher should not know or care if there are any subscribers out there, nor should it care what the subscribers do if they are there (from Brian Noyes' blog)

在 Prism 中使用 EventAggregator 的最佳实践是什么？目前我有几个模块松散耦合并且独立工作。这些模块使用 EventAggregator 与其他模块通信。随着应用程序的增长，我对如何记录我的代码感到困惑。可能有许多模块发布事件和许多其他订阅它，因为布赖恩说他们都不知道其他人到底在做什么。创建新模块时，如何确保它们订阅了某些 XYZ 事件而不破坏松散耦合的结构？

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

Answer 1

您的帖子中有很多问题可以回答“这取决于您的应用程序”，但我会尝试回答其中的一些问题。

我在 EventAggregator 中最常看到的一件事是滥用。许多人使用 EventAggregator 的方式使发布者和订阅者相互依赖。这给我带来了我的第一个建议:

永远不要假设某个事件有任何订阅者。

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

在适当的情况下优先使用 .NET 事件而不是 EventAggregator 事件

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

我看到很多变化是从父 View 到 subview 的通信，反之亦然。诸如“TreeItemChecked”或“ListViewItemSelected”之类的东西。在这种情况下，将使用传统的 .NET 事件，但作者决定，如果他们有一把锤子 (EventAggregator)，那么一切 (Events) 看起来都像钉子。

您询问了 建模 EventAggregator 我想说的是:EventAggregator 的特殊之处在于它允许解耦并且不会创建对事件的强引用(避免内存泄漏等)。除此之外，它实际上只是 Observer Pattern 的一个非常轻微的变化 .但是，您正在建模 Observers 是如何在您尝试创建的任何类型的图表中对 EventAggregator 进行建模。

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

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