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