DAO是J2EE設計模式中一種重要的設計模式。它上與BO（Business Object）業(yè)務邏輯層相連，下與數(shù)據(jù)源逼近，其重要性就不言而喻了。
舉一個簡單的例子：分頁。分頁是系統(tǒng)中非常常見的功能模塊。我們用兩種方式來模擬一下這個功能：純凈的JSP，還有JSP+DAO。
純jsp的方式：我們會在頁面里直接直接上sql語句：SELECT ...FROM ... LIMIT n,m。如果我們系統(tǒng)中有好多個模塊都要用到分頁的功能，那這塊管理分頁的程序會立馬出現(xiàn)在好多個頁面上，這時候再加上數(shù)據(jù)庫的連接關閉，或者其他的業(yè)務代碼，我們的頁面會顯得很亂，不好維護。而且從代碼復用的角度來說這樣就不很合理。
下面我們看一下：JSP+DAO：我們可以完全把與數(shù)據(jù)庫有關的操作交給DAO層來管理，數(shù)據(jù)庫的連接關閉，分頁的邏輯，或者你的jsp頁面中還有其他操作數(shù)據(jù)庫的業(yè)務代碼，不要猶豫了放心的交給DAO吧！這樣我們的頁面上就不會出現(xiàn)相當惡心的有關數(shù)據(jù)庫操作的代碼了，整個JSP頁面清爽了好多。而且其他模塊在使用分頁功能的時候就可以直接去調(diào)用已經(jīng)封轉(zhuǎn)好的DAO了。可能例子有點極端，但是只是想說明一下DAO多么的有用，希望目的達到了！
我們來總結(jié)一下dao在我們系統(tǒng)中都做了什么：DAO完全隔離了系統(tǒng)中業(yè)務邏輯層和數(shù)據(jù)訪問層。數(shù)據(jù)訪問集中在DAO這一層中，方便我們進行集中的管理，系統(tǒng)的層次性更好了，為后期的系統(tǒng)維護提供了一定的便利。DAO 還有助于提升系統(tǒng)的可移植性。獨立的 DAO 層使得系統(tǒng)能在不同的數(shù)據(jù)庫之間輕易切換，底層的數(shù)據(jù)庫實現(xiàn)對于 BO 來說是不可見的。數(shù)據(jù)移植時影響的僅僅是 DAO 層，切換不同的數(shù)據(jù)庫并不會影響 BO，因此提高了系統(tǒng)的可復用性。
DAO其實也是面向?qū)ο蟮囊环N設計，因為系統(tǒng)中所有的操作數(shù)據(jù)庫可以看作是同一種行為，所以我們就可以”面向?qū)ο蟮?ldquo;抽象出一個專門的對象管理負責這一塊。系統(tǒng)中如果有數(shù)據(jù)庫的操作，那就很便捷了，對DAO說：”我要操作數(shù)據(jù)庫了，給我連上數(shù)據(jù)庫，然后給我拿出我昨天存入數(shù)據(jù)庫的數(shù)據(jù)...“。然后你就等著就行了。聽起來非常的爽，用起來是更爽。
但是這種“爽”是建立在對DAO正確的封裝和使用的基礎之上的。如果你用的不合理，也會非常的別扭。
DAO（Data Access Object 數(shù)據(jù)傳輸對象）是若干個原子操作組成的集合。他的特點是執(zhí)行最基本的數(shù)據(jù)庫操作CRUD（增刪改查）。我們在設計程序的過程中不要對DAO層施加任何的業(yè)務邏輯，如果這樣的話你抽象出這樣的DAO層就完全沒有意義了，那么直呼它為service或許更合適，業(yè)務邏輯專門有我們的service層或者action層。反正DAO肯定不適合處理業(yè)務，好像趙本山小品中”公雞下蛋“，你讓它干了它不該干的事情，他心里能好受嗎？我不知道程序要是心里不好受了他會干出什么壞事，破壞程序的可讀性，減低代碼重用率，增加代碼維護的難度....因為我還是一只菜鳥，所以我不能預知后果！！呵呵姑且就當后果很嚴重吧！不負責任的猜測程序的效率也可能會受到影響：因為把業(yè)務交給了DAO，DAO里離數(shù)據(jù)庫最近，難免不了數(shù)據(jù)庫“替”DAO處理業(yè)務邏輯，那么相當于mysql也做了不該干的事。
Java是一種”大腕“語言。就拿一個登錄框架來說，有的人兩個個頁面可以搞定，有的人卻可以想到用SSH來“架構(gòu)一下”。我真正接觸java的時間也差不多有一年多了，我也深有體會（說深有體會其實是騙人的，上面說了我還是一只菜鳥，哪能深有體會呢）。但這不是java的缺點，而是好多人（更準確的說是像我們這樣的一群菜鳥），努力地想使用更多的東西比如說SSH來炫耀自己的“功力”。真正的架構(gòu)應該根據(jù)需求來定，好比說一個登陸框架你就沒有必要SSH了，但是如果你想做一個面對用戶千百萬，程序代碼百十來萬行，那么你還用純jsp，那不是開玩笑嗎！
合理利用java中的各種模式和框架，不過說起來容易做起來難呀！！純個人胡言亂語，請前輩們不吝賜教，感激不盡。