本文地址：http://blog.csdn.net/sushengmiyan/article/details/50178231 作者：蘇生米沿 DAO模式起源于sun的java藍皮書，已經有15個年頭了。一個DAO類定義了一個接口，用于操作與特定實體相關的持久化操作，它建議你將跟這個實體相關的代碼都聚合在一起。考慮到時間之久，現在已經出現了多種多樣的DAO模式，我們推薦一種模式如下：  我們將持久化層分為兩個平行集成層次，一邊是接口，一邊是實現。基本的實例存儲和檢索操作都被包裝在一個超接口和實現這些操作的超類中，它們都帶有一個特定的持久化解決方案。一般的接口可以通過擴展實現自己的特殊的業務實體要求，同樣的，你可以實現一個或多個DAO接口。 ?我們快速的看下這個結構。它囊括了一堆的查找方法，典型的，這些方法都會返回被持久化管理的實體實例，他們也可以是任意的數據傳輸對象，如ItemBidSummary.。查找方法是你代碼復用的一個最大問題，如果你不小心翼翼的規劃，你可能會已雜亂的幾十個結束。第一步就是讓它們盡可能的通用，讓它們在集成的高層次，理想情況是接口的頂層。看一下ItemDAO中的findByName()方法，你很可能在后期會增加更多的方法，或者你會想數據在數據庫中返回時是有順序的，或者你將會實現一些類似分頁的操作。 DAO api提供的方法明顯的表明，這是一個狀態管理的持久化層次。像makePersistent()和akeTransient()方法改變實體的狀態。 我們這里說的持久化層并沒有將JPA或者其它實現接口暴漏出來，所以你可以在任意的更換實現，對客戶端是沒有影響的，理論上來說。 如果你想客戶端也要訪問原生的方法，那么就需要你暴漏出來了，那就是另一個設計方法了。 微信訪問地址：http://mp.weixin.qq.com/s?__biz=MzA3MTU1NjM4MQ==&mid=400752253&idx=1&sn=8ee3b70dd2d8f33963888abfd487dbd9#rd