通常，我嘗試以這種方式構建我的DAO類，以使它們完全依賴於自己。它們可以與多個表進行交互，但前提是數據與基礎對象相關。例如，假設我有一個約會對象，並且約會DAO從約會表中提取數據。如果約會表是一個服務id，它是一個將約會綁定到服務的外鍵，那麼讓我們說一列。服務表完全獨立於約會，並擁有自己的DAO，用戶可以在其中添加或刪除服務。DAO類應該依賴於其他的dao類嗎？
約會對象有一個服務字段，用於存儲服務對象。我這樣做是因爲在許多情況下，在處理約會時必須引用這個服務對象。
在約會DAO中，我可以編寫單獨的SQL語句以從其表中提取服務數據，並在約會DAO中重新映射所有這些，但所有這些都已在服務DAO中完成，並且將如調用serviceDao.find（serviceId）。我在約會DAO中引用了服務DAO，感覺有點骯髒。這是因爲我有設計問題還是可以做這種事情？我試過研究這個問題，結果是50/50。
爲什麼有一個服務DAO指向另一個如此糟糕？
您需要注意的一個問題是延遲造成的死亡。如果你的服務DAO帶回了N個實例，然後你循環這些結果來恢復其他東西，那麼你將有N + 1個查詢 - 和N + 1個網絡往返 - 在一個JOIN中一次往返將帶來所有數據立即恢復。
我建議您不必擔心DAO，更多關於編寫最好，最有效的SQL。
我不確定是否有特定的「標準」，但我通常是以商業意義而不是實體組織我的DAO。因此，如果約會和服務通常以某種形式相關，我可能最終將它們放在一起。也許像AppointmentServicesDAO（如果這是一個合適的名稱）。每個實體擁有一個對象更適合模型而不是DAO。
我同意你的感覺很髒。我通常不喜歡在DAO中調用其他DAO。如果需要在課堂上進行某種分離，可能需要一些基本的繼承。
但是，我還沒有研究標準硬核。大部分來自經驗，所以如果有人有更好的建議，會喜歡聽到他們。
Ya。保持約會和服務的道理是分開的，因爲它們也是分開使用的。例如，服務也用於許多其他對象。但在這種情況下，任命完全依賴，所以即時通訊掙扎。將dao中的約會服務對象映射爲更有意義，而不是將id存儲在對象中，並將該字段分別填充到控制器中。 – ryandlf
我會通過id引用屬於其他DAO的對象（在您的示例中是一個「服務」ID），並使用對象緩存清理分離兩種類型的對象。 30。
有道理。我想有時候我們只是被設計主體卡住了，出於某種原因，我一直試圖保留按表組織的daos（或者多個表，如果其他表只由父級引用）。那麼，你的建議是使用連接嗎？還是要依靠其他的道？在我的情況下，對db的調用會返回一個serviceId，然後當我映射約會bean時，我會調用服務dao來獲取該對象的數據。 – ryandlf