N層發佈/訂閱者設計問題

Question

我正在研究如何編寫一個好的軟件系統的體系結構，並且我正在學習如何將高層組件分離爲層。 在這種情況下，我試圖使用層，以便將每個圖層建模爲黑色 框。

我的架構中有4層：Presentation，Application Services， Business Logic和Domain/Persistence。對於我的問題， 我們只需要關注演示和應用服務。

應用程序服務層將包含一項服務，該服務允許跟蹤某個事件的 。演示文稿將包含幾個視圖，當事件的跟蹤模型更改時， 會動態更新。本質上， 似乎我需要一個單向變化傳播機制。

由於我試圖這些層作爲層級模型，我想門面對象之間的限制每一個Tier通信 ，並在必要時，允許層 從一個層下聚合的對象，雖然只由接口知道。

我正在用Java編程這個應用程序，因此使用的顯而易見的東西是 Observable/Observer。但是，我不喜歡 Observer界面的更新方法強制您投射對象參數。我想通過爲這個機制定義我自己的接口和類來解決 這個問題。該問題， 話，就是應用邏輯將取決於在接口上從Presentation 層，有一定沒有沒有此架構。這是一個跡象，我應該嘗試使用MVC最前沿建模 和層模型？或者， 模型中的每個視圖都有一個更好的主意，其中應用程序服務層中有一個已知的接口。 這似乎是一個不好的地方，我被卡住了。另外，我使用View-Handler設計模式來處理多個視圖。

Answer 1

Observer/Observable通常是而不是最好的方法，尤其是在Java中，您必須從Observable派生，因此會浪費您的單一繼承。正如你所討論的那樣，它也會在跨層時引起耦合，這是很糟糕的。

我會更傾向於以調查一個純粹的事件模型，與服務提供的方式，當變化發生時註冊事件偵聽器，燒結，也許，一個PropertyChangeEvent。

服務層然後可以通知其他服務或通知表示層 - 它不知道也不關心，並且只有該表示通過註冊爲監聽器而耦合到服務。

Answer 2

在我看來，你的問題不在於發佈/訂閱，而在於如何讓圖層進行通信。

簡短回答：

使用MVC/MVP。查找關於他們的博客文章，下載源代碼，並記住：如果你擁有的只是一把錘子，那麼所有東西看起來都像釘子。含義不適用模式，因爲您擁有它們，因爲需要它們而應用它們。

龍答：

如果你在Java中的工作，我認爲這將讓你面向的模式思維方式Head First Design Patterns。在您瞭解設計模式之後，您可以看看Patterns of Enterprise Application Architecture。可以免費跳過Head First，但如果您正在進入建築學，那麼我強烈建議您閱讀這本好書。

一旦消化了福勒書，或者至少對N層企業架構有了基本的瞭解，您就應該順利完成。