很多的J2EE應用程序需要使用持久性數據(數據庫、文件等)。不同的程序，持久性存儲是各不相同的，并且用來訪問這些不同的持久性存儲機制的API也有很大的不同。如果應用程序要在不同的持久性存儲間遷移，這些訪問特定持久存儲層的代碼將面臨重寫。
如何解決這個問題?且看"DAO模式"

數據訪問對象(Data Acess Object) 模式
一.環境
根據數據源不同，數據訪問也不同。根據存儲的類型(關系數據庫、面向對象數據庫、文件等等)和供應商實現不同，持久性存儲(比如數據庫)的訪問差別也很大

二.問題
許多真是的J2EE應用程序需要在一定程度上使用持久性數據。對于許多應用程序，持久性存儲是使用不同的機制實現的,并且用來訪問這些不同的持久性存儲機制的API也有很大的不同。
比如，應用程序使用實體bean(這里應該是指BMP的bean，CMP的bean已大大降低了與RDBMS的耦合)的分布式組件來表示持久性數據，或者使用JDBC API來訪問駐留在某關系數據庫管理系統(RDBMS)中的數據，這些組件中包含連接性性和數據訪問代碼會引入這些組件與數據源實現之間的緊密耦合。組件中這類代碼依賴性使應用程序從某種數據源遷移到其他種類的數據源將變得非常麻煩和困難。當數據源變化時，組件也需要改變，以便于能夠處理新類型的數據源

(舉個例子來說，我們UPTEL系統是使用JDBC API對 ORACLE數據庫進行連接和數據訪問的，這些JDBC API與SQL語句散布在系統中，當我們需要將UPTEL遷移到其他RDBMS時，比如曾經遷移到INFORMIX，就面臨重寫數據庫連接和訪問數據的模塊。)

三.作用力
1.諸如bean管理的實體bean、會話bean、servlet等組件往往需要從持久性存儲數據源中檢索數據，以及進行數據存儲等操作。
2.根據產品供應商的不同，持久性存儲API差別也很大，這些API和其能力同樣根據存儲的類型不同也有差別，這樣存在以下缺點，即訪問這些獨立系統的API很不統一。
3.組件需要透明于實際的持久性存儲或者數據源實現，以便于提供到不同供應商產品、不同存儲類型和不同數據源類型的更容易的移植性。

四.解決方案
使用數據訪問對象(DAO)模式來抽象和封裝所有對數據源的訪問。DAO管理著與數據源的連接以便檢索和存儲數據。
DAO實現了用來操作數據源的訪問機制。數據源可以時RDBMS,LDAP,File等。依賴于DAO的業務組件為其客戶端使用DAO提供更簡單的接口。DAO完全向客戶端隱藏了數據源實現細節。由于當低層數據源實現變化時，DAO向客戶端提供的接口不會變化，所有該模式允許DAO調整到不同的存儲模式，而不會影響其客戶端或者業務組件。重要的是,DAO充當組件和數據源之間的適配器。

(按照這個理論，如果我們UPTEL系統使用了DAO模式,就可以無縫的從ORACLE遷移到任何一個RDBMS了。夢想總是很完美的，且看看DAO模式如何實現)