正面和DAO之間有什麼圖案？

Question

我正在爲其Java EE Web應用程序設計公司架構的一部分。我很清楚使用立面和一個或多個DAO的原因。我遇到的問題是這樣的：

肯定會有一些邏輯肯定屬於集成層，因爲它全部關於保持數據模型一致。除了邏輯不僅僅是維護參考完整性和JPA和Hibernate將要處理的其他「原始」持久性任務之外。我不會將其作爲業務邏輯分類，因爲它與任何業務功能都是分開的。然而，我的理解是DAO應該只實現訪問和持久化對象到數據源所需的邏輯。

我的結論是，我需要一個適合集成層的「業務對象」模式。我環顧四周，發現了最接近的東西（但我仍然不太清楚）是Sun Transfer Object Assembler pattern。

我對Java EE的理解存在差距，或者存在適合的模式。

Answer 1

也許mediator是你想要什麼：

來封裝如何一組對象進行交互的對象。介體通過讓對象明確地互相引用來促進鬆散耦合，並且可以讓您獨立地改變它們的相互作用。

那麼你可以使用一個DaoMediator爲了協調兩個或兩個以上DAO小號

Answer 2

這聽起來像你可能錯過了一個控制器，因此可能需要MVC模式。控制器將關注DAO並呈現一致的視圖（不要認爲是GUI，而是一些面向客戶端的界面）。通過此視圖進行修改時，控制器通過DAO協調對模型的更改。我懷疑你的外觀對象可能是這種情況下的視圖。

話雖如此，我不會擔心太太多關於識別特定的模式。您經常會發現，考慮到您的所有要求並在適用的情況下將問題分開，最終實現某種特定模式並且僅在事實發生後才確定它。

Answer 3

我認爲這是您的DAL和業務層之間的DataMapper（或適配器）模式，但沒有更具體的理解，我無法確定。

Answer 4

你有沒有考慮使用集合從領域驅動設計？ 我是DDD的學生，看起來您嘗試設計的業務邏輯可以通過更豐富的POJO類域模型來完成。你會讓每個域對象負責其聚合對象，並且還包括任何有關該商業概念的邏輯;那就是說，你的整合層可以協調那些豐富的對象，但是本身不會有真正的邏輯（即幾個條件邏輯）。

也許你試圖找到的模式實際上是進入更豐富的域對象的一步？

Answer 5

推動DAO之間一致性的要求是什麼？如果有一些商業假設是支配關係的話。例如，您可能有一個發票類型，當它是'資本'時，我們必須確保其他幾個對象處於正確的狀態或具有正確的一組值。這絕對超出了數據層領域。

我不會盡力去尋找這種情況下的完美模式。你需要某種協調類，某種協調者或控制者。