如何设计棱镜EventAggregator？

Question

模式的发布 - 订阅事件是， 出版商不应该知道或关心 有任何用户在那里， 也不应该关心什么，如果他们是 用户那里做（从 Brian Noyes' blog）

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

如何以可视方式（某种图表）使用EventAggregator表示模块？

Answer 1

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

我最常看到EventAggregator的一件事是滥用。许多人使用EventAggregator的方式使发布者和订阅者彼此依赖。这给我带来了我的第一点忠告：

永远不要假设有事件的任何subscibers。

EventAggregator是发布事件的其他意见威力感兴趣的是有用的。例如，在我们的应用中，我们允许用户改变某人的名字。该名称可能会显示在应用程序中已打开的其他视图中（我们有一个选项卡式UI）。我们的用例是我们希望在更改名称时更新这些UI，因此我们发布了一个“UserDataChanged”事件，以便打开的视图可以适当地订阅和刷新其数据，但如果没有任何已打开的视图对此数据感兴趣，没有订户通知。

在适当

另一个错误我经常看到EventAggregator事件青睐.NET事件是使用EventAggregator那里数据被发送到中央党和该方的答复，全部采用EventAggregator实现业务流程。这会导致一些你可能想避免的副作用。

我看到很多的变化是从父视图到子视图的通信，反之亦然。像“TreeItemChecked”或“ListViewItemSelected”。这是一个使用传统.NET事件的情况，但作者认为如果他们有锤子（EventAggregator），那么所有事件（Events）看起来都像钉子一样。

---

你问到造型EventAggregator，我会这样说：EventAggregator仅特殊之处在于它允许解耦，并且不产生事件（避免内存泄漏等），强引用。除此之外，它实际上只是Observer Pattern的一个非常微小的变化。然而，您正在建模Observers是如何在您试图创建的任何类型的图表中对EventAggregator建模的。

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

要记住你的模块的事情是，你应该能够完全删除一个和其他应用程序功能通常。如果情况并非如此，那么您或者具有模块依赖性（最好避免，但是可以理解），或者依赖模块应该合并为一个。