DAO和服務？

Question

我總是面臨一個問題，我無法真正想到封裝了許多DAO方法的服務對象。

我的意思是，對於我的servlet，有時使用單個DAO方法就足夠了，例如addUser（User params）。

更好的做法是 - 使用服務對象封裝DAO方法並僅使用服務對象，即使它實際上意味着單個服務方法調用單個dao方法或將它們的使用混合在一起（來自服務對象的一些方法和來自servlet中的dao的一些方法）上下文） - 意味着我在控制器內部自動裝配了DAO和Service對象？

如果我開始在同一個地方同時使用DAO和Service對象，它會混淆邏輯嗎？

Answer 1

我認為這取決於具體情況。 如果沒有DAO會導致混合業務邏輯和數據訪問邏輯，那么最好有單獨的類。

但是，如果您的DAO是“虛擬”並且只調用EntityManager方法，則可以直接在服務對象中使用它。 我們的想法是讓課程具有單一職責 ，並且易於擴展和測試。 你不應該為它創建圖層。

如果您想保留可重用的服務層，我可能不會直接從您的控制器使用DAO。 如果DAO沒有意義，我寧願在服務層使用EntityManager（或者你正在使用的任何持久性策略）。

Answer 2

我正在使用一個系統，其中“你不能讓控制器與DAO交互！” 設計理念在某一點上被接受，並且為每個組件創建了服務層。 正如您所描述的，大多數服務只是委托給DAO。 我反對這一理念有兩個原因。

一個是好老“你不會需要它”。 在您需要之前不要實施某些東西。 只是因為你預見到某種原因需要額外的間接層來做一些額外的邏輯，所以你不確定你是否會需要它。 當你最終需要它時，你可能會發現你的期望與你之前認為的不符。 而且你得到額外的成本，因為現在你必須對兩個類進行單元測試而不是一個，並且你需要在兩個地方而不是一個地方添加方法並不罕見。

第二個是，到底是什么服務呢？ 當我為自己的域建模時，我會嘗試用面向對象的術語來思考。 有用戶，因此User類是有道理的。 有新聞項，因此NewsItem類是有道理的。 但我甚至不知道UserService應該做什么。 包含用戶的“業務邏輯”？ 不，這就是User類的用途。

如果你需要為“外部世界”維護一個嚴格的API，那么我可以看到一個案例，讓一個額外的層保持不變。 但在所有其他情況下，你不會需要它。

Answer 3

要看。 分離DAO和服務層的原因通常是：

• 技術限制（參見其他答案中的AOP交易）
• 架構約束（DTO <=>服務層和DAO之間的@Entities轉換）
• 歷史（這是X年的工作方式）
• 美學（只從視圖層訪問一個圖層）

使用Java EE 6（JBoss AS 7），我沒有這些負擔：

• 沒有AOP - @Stateless和@Transactional負責交易。
• 沒有DTO - 我使用JPA的@Entities直到視圖層。
• 不關心歷史。
• 我更喜歡簡單/更少的代碼而不是美學。

所以我在DAO層中有大多數方法。 對於某些情況，更復雜的操作，我創建了一個服務bean，並且可能使用擴展的持久化上下文 。

我的經驗法則是，方法是否應該進入Service bean：

1. 如果它使用多個DAO（顯然）
2. 如果它執行多個實體管理器調用
3. 如果實現可能會改變，例如在JPQL與Hibernate Search與ElasticSearch中進行搜索。

Answer 4

就個人而言，我通常在服務中封裝DAO調用。

這允許我使用AOP /等進行所有服務交易。 並在這些服務中使用非事務性DAO方法。

對於普通服務，這是一個額外的“層”，但IMO服務於一個目的（並且無論如何都可以使用一種或另一種代碼生成來生成它）。 這也是罕見的，我只有在服務結束了DAO功能，雖然。