如何設計棱鏡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。在這些情況下，我會建議在您的應用程序中運行一個服務，以便模塊可以從您的容器中抓取並使用其他類似的東西。

要記住你的模塊的事情是，你應該能夠完全刪除一個和其他應用程序功能通常。如果情況並非如此，那麼您或者具有模塊依賴性（最好避免，但是可以理解），或者依賴模塊應該合併爲一個。