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

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

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

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

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

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

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