什麼是更好的：允許服務訪問多個DAO或只有其他服務

我還沒有發現任何問題，解決這一特定問題。有什麼更好的：允許服務（或外牆）訪問多個DAO（與數據庫交談的類）或只有其他服務？什麼是更好的：允許服務訪問多個DAO或只有其他服務

換句話說，我應該在不同的Service類之間引入相互依賴關係還是通過向每個Service類注入多個DAO（如有必要）使Service類彼此完全獨立更好？

我發現兩種策略都能完成這項工作，但我希望保持一致並儘可能使模塊化和可維護性成爲可能。

來源

2012-02-22 Renato

我覺得允許或禁止一個服務調用另一個服務或一個以上的DAO是主觀的。我儘量避免不必要的代碼或奇怪的耦合，只是爲了滿足一些關於層次通信的規則，遵循基本的OO原則來製作簡單明瞭的對象通常會導致妥協。

如果一個服務B需要另一個已經包含在服務A中的功能，那麼它應該調用它。我試圖減少服務之間的依賴關係，通常最終定義一小組可以從其他服務調用的「基本」服務。
在一個服務中創建一個方法只是將一個調用包裝到DAO中是毫無意義的（在我看來），因此我更願意讓服務根據需要調用盡可能多的DAO。同樣，具有多個DAO的服務或方法表明應重構某些內容或需要調整的數據模型。

來源

2012-02-22 01:34:07 madth3

所以你建議創建一類特殊的「基本服務」，這是「正常」服務可以使用的唯一服務？並且還允許在服務之間共享DAO（例如，爲了避免包裝DAO方法以供其他服務使用）？對我有意義，但這是一種混合策略（通常，混合策略是最好的，儘管它們使代碼更不一致）。 – Renato 2012-02-22 01:45:28

如果你喜歡，可以做一個特殊的'BasicService'。從來沒有做過，因爲我通常以很少的人結束。所以，這是一種傾向於獨立服務的混合策略。 – madth3 2012-02-22 01:58:05

有一些意見可以肯定，但真正的「服務」方法應該是一個原子工作單元。如果他們正在創建一個互相依賴的網絡，互相調用對方，顯然這些調用不會執行原子任務。讓我看到讓一個「服務」使用它需要的任何DAO都沒有錯。創建一組抽象DAO的「服務」 - CRUD方法，這個方法已經是CRUD方法的集合，它本身可能會抽象出JPA的抽象，你可以看到這可能是一個太多的非功能抽象層次。

這種方法有時會導致您構建共享的「業務bean」，它們位於域中，而不是服務中的多個服務共享。這可以。

（你能告訴我個人認爲JPA已經取得的DAO過時的整個想法，我們應該只使用的EntityManager的服務？:)）

來源

2012-02-22 01:35:54 Affe

什麼是更好的：允許服務訪問多個DAO或只有其他服務

回答

相關問題