DAO（Data Access Object）模式可以看成是Data Accessor模式 與 Active Domain Object模式；前者實現(xiàn)了數(shù)據(jù)訪問和業(yè)務(wù)邏輯的分離，后者實現(xiàn)了業(yè)務(wù)數(shù)據(jù)的對象化封裝。結(jié)合在一起即是對數(shù)據(jù)訪問的封裝。
? DAO模式往往用于數(shù)據(jù)庫的JDBC操作中，最主要的應(yīng)該就是事務(wù)。JDBC 事務(wù)是用 Connection 對象控制的，默認(rèn)的事務(wù)模式是事務(wù)自動提交，如果采用“手工”管理，需要把Connection對象的自動提交功能設(shè)置為false，即conn.setAutoCommit(false)，在提交時使用conn.commit();才正式提交事務(wù)。
???DAO的職責(zé)：每個類對一個數(shù)據(jù)表進行維護，即增/刪/改只針對一個表，查可以連接多個表并返回業(yè)務(wù)對象（Business Object）。
???問題就出現(xiàn)在DAO既然只是針對一個數(shù)據(jù)表進行維護的，但在一個業(yè)務(wù)邏輯操作中，業(yè)務(wù)對象可能需要好幾個DAO來共同服務(wù)。
???一個較好的原則就是一個業(yè)務(wù)對象的一次具體操作最好能在一個事務(wù)中完成。拋開應(yīng)用服務(wù)器提供的可能的JTA不談，不妨把Connection的獲得放到業(yè)務(wù)對象的方法中，在每個DAO的方法中增加Connection作為參數(shù)；在業(yè)務(wù)對方的方法體最后關(guān)閉這個連接。這樣，就形式上與多個SQL語句組合在一個事務(wù)中有相同的效果。
???另外，對于一些業(yè)務(wù)對象，其并不涉及多個DAO操作，是否還需要這樣來做呢？當(dāng)然這樣做也無可厚非，但不妨在DAO的方法中同時提供有Connection和無Connection參數(shù)的兩種方法；這樣就比較容易處理了。
???雖然JTA及其容器的事務(wù)聲明方式更簡單，但是如果在沒有提供JTA功能的容器比如Tomcat下運行，這樣也不失為一種解決辦法.
???寫完了，在封裝一些方法時，突然想起來了，如果對連接用的是連接池，Connection創(chuàng)建、關(guān)閉好像沒有什么問題哦，也就不用上面的方式了。
??? 附：如果不當(dāng)之處，請跟貼討論，拒絕過于偏激的言論。