我正在尋找在Data Access Object設計模式的反饋和使用它時，你必須在多個表中的數據。對於每個表具有DAO以及表示單行的數據傳輸對象（DTO）的模式似乎不太適用於處理來自多個表的數據。我正在考慮創建一個將返回結果的組合DAO和相應的DTO，讓我們假設在兩個表上執行連接。通過這種方式，我可以使用SQL獲取所有數據，而不是先使用一個DAO抓取數據，然後使用第二個DAO抓取數據，然後使用Java將它們組合在一起。DAO設計模式，並用它在多個表
有沒有更好的解決方案？不，我目前無法轉移到Hibernate或其他ORM工具。這個項目只需要JDBC。
我會用你的方法一致。我的DAO傾向於更多地在對象級別進行對齊，而不是從數據庫表視角進行對齊。我可以通過DAO管理多個對象，但它們很可能是密切相關的。沒有理由不讓SQL訪問生活在一個DAO中的兩張表。
並記錄在案，我從我的詞彙和代碼放逐的縮寫DTO。
理想情況下，你如何存儲你的數據在數據庫中，然後你如何訪問它們，應該從你的域模型域實體之間的關係的性質的。也就是說，關係模型應該遵循域模型。例如，如果您有兩個實體，例如用戶和地址。
場景＃1：地址永遠不會獨立訪問，它們始終是用戶的屬性。 在這種情況下，Address是一個Value Object，User是一個實體，並且有關於如何存儲這種關係的指南。一種方法是將地址的地址屬性與用戶的屬性一起存儲在單個表中。在這種情況下，UserDao將處理這兩個對象。
場景＃2：地址可以關聯到一個用戶，但也可以是它自己獨立的一個實體。 在這種情況下，需要一種與第一種不同的方法。您可能有一個單獨的DAO和地址類型表。
我的觀點是，更多的時候這一重要思想被忽略的領域模型應該是應用程序的核心，帶動其他層。例如，如果你的域模型是正確定義的，並且你很清楚你擁有的實體的類型以及它們之間的關係，那麼你的持久性（關係表和它們的關係，你的DAO等）將隨着這是您在領域模型中具有的非常合乎邏輯的結果。換句話說，如果你花一些時間研究你的模型，你將能夠在確定如何將DAO組織到域模型中的某個位置時跟蹤你的問題。如果您可以在領域模型中清楚地定義對象的類型以及它們之間的關係的性質，它將幫助您解決DAL層中的問題。
「我從我的詞彙和代碼放逐的縮寫DTO。」你能解釋更多嗎？ – Casey 2010-03-24 02:24:45
我只是沒有看到調用一個對象'數據傳輸對象'的觀點。我直接在我的DAO中填充域對象，在我的服務中使用它們，並將它們暴露在我的視圖中（有時我可以創建替代視圖對象）。 DTO通常沒有任何行爲，並且是愚蠢的財產持有者。我沒有看到在現代Java項目體系結構中限制我的對象的理由。而現在，我通常指的是非EJB，像Spring這樣的框架。 – pkananen 2010-03-24 04:41:32
我明白了。幾乎和我一樣使用它們。謝謝。 – Casey 2010-03-24 12:33:37