引發這個問題的代碼是我公司代碼庫中的一個服務，它包含四個不同的DAO。直到我看到該服務已經與屬於完全不同的服務的方法混爲一談時，我纔想到這一點。在這個服務中創建這些無端的方法的原因僅僅是因爲所需的DAO是這個服務類的私有成員。服務和DAO之間的關係應該是一對一還是一對多？
這位開發人員是否違規，或者在大多數情況下每個服務級別擁有多個DAO都是錯誤的？
注意：我注意到每個Service類有多個DAO似乎是合理的，只要它們都包含在同一個數據庫中。但是，從多個數據庫中獲取DAO似乎可能會導致問題。
我看不出每個服務類有多個DAO。多年前，當我第一次開始web開發時，我有一個DAO服務，因爲這似乎是最合乎邏輯和最直接的方法。然後，我開始看到服務於不同服務的DAO之間存在類似的API的問題。因此，我的「不成熟」解決方案是將這些通用API推廣到一些父DAO，以便由這些DAO繼承。當項目發展時，它已經到了繼承沒有任何意義的地步，因爲我有80％的兒童DAO需要這個API但20％不需要，但他們仍然繼承了同一個父項DAO，因爲他們共享其他類似的API。你看到這裏的問題？我的意思是，在Java中，你只能從一個父代繼承，所以我最終填充了「可能」被DAO中的「多數」DAO使用的填充API，這完全違反了繼承原則。
現在，我所有的DAO類都有特定的職責/任務。 DAO調用另一個DAO是可以的（例如，大多數DAO使用LoggingDAO來記錄用戶操作）。通過這種方式，DAO提供了一個可能使服務受益的操作列表，而不是具有一個爲特定服務提供服務的DAO。該服務將「使用」任何將完成任務的DAO。
希望這個解釋有幫助。
只要分解DAO是有意義的，一對多都可以。
一對夫婦的原因，我能想到的地方是有意義的分割DAO：
在我工作的一家公司，他們有一個很好的設計，其中服務稱爲控制器，控制器可以調用另一個層，但我不記得，但那會調用DAO。
因此，他們有一個訪問級別可以調用多個DAO，以便執行更高階的函數，因此，如果您想要執行一個命令，它可能需要調用多個表，也可能需要調用多個系統，所以控制器會調用doOrder方法。
這是一個不錯的設計，因爲它可以保持良好的分離感，並使得單元測試更簡單，因爲您可以測試每個圖層。
如果您的服務能夠調用多個DAO，那麼隨着服務層更加複雜，單元測試可能會更困難。
所以，當你設計你的圖層時，看看是否有意義創建新圖層來簡化設計，這可能會發現錯誤或防止錯誤。
UPDATE：
的缺失層是協調和規則是每個協調處理了一個DAO，並能做到就必須採取任何轉換，但商業邏輯是在控制器中。因此，協調員可以與任何其他協調員交談，獲取信息，協調員將前往DAO。
它的確如此。在我的情況下，我認爲我正在處理開發人員的不當行爲，在這種情況下，人們根據其DAO字段將內容推送到Service中，而不是基於服務的意圖。 – stevebot 2011-01-25 01:58:04
啊，遺傳和亞型多態性的問題...所有這一切，不錯的軼事;-) – 2011-01-25 01:59:43
在我看來，一個服務提供了一組特定的服務來處理一些用戶操作。這些服務可能會也可能不會使用DAO來完成這項工作。另一方面，DAO提供Service和數據庫之間的通信，但它不應該知道用戶請求的全部內容。如果開發人員將這兩者混合在一起，那麼我沒有看到具有服務和DAO的一點，因爲您可以將它們組合在一起，這非常糟糕，因爲您無法重新使用大量代碼。 :) – limc 2011-01-25 02:08:24