基于JavaEE的分布式三層企業(yè)級應(yīng)用的數(shù)據(jù)存取方式有很多種，比如關(guān)系型數(shù)據(jù)庫、普通文件、遠(yuǎn)程服務(wù)等。但是數(shù)據(jù)的存取主要采用關(guān)系型數(shù)據(jù)庫，下面主要關(guān)注關(guān)系型數(shù)據(jù)庫的持久層開發(fā)方式。
開發(fā)方式大體以下幾種方式（括號內(nèi)為目前使用它的工作難度、強(qiáng)度，記住，我們討論的是動輒就上百個表、幾個業(yè)務(wù)小組聯(lián)合開發(fā)的企業(yè)級應(yīng)用，所以工作強(qiáng)度的估計一點兒也沒有夸張）：
-
直接JDBC操作（簡單，小）：底層操作（注1）較多，弄不好就會造成業(yè)務(wù)邏輯層和持久層的高度耦合。
-
SQLMapping（比較簡單，一般）：把底層操作全部提取出來統(tǒng)一進(jìn)行管理，本身并沒有對概念上進(jìn)行什么革新。但是這種統(tǒng)一的處理在邏輯上其實屬于分而治之的邏輯，通過良好的對它的使用可以體現(xiàn)出松耦合實現(xiàn)持久層的要求，也相對比較便于管理和修改。
-
O/RMapping（有學(xué)習(xí)曲線，沒有工具支持會相當(dāng)大）：存在的時間已經(jīng)很長，我認(rèn)為它的最主要的作用是關(guān)系型數(shù)據(jù)庫的反設(shè)計——關(guān)系型數(shù)據(jù)庫的設(shè)計
就是要把現(xiàn)實中的對象和對象間關(guān)系設(shè)計成實體和實體間的關(guān)系映射。而O/RMapping恰好相反，它是把實體和實體間的關(guān)系映射還原回對象和對象間的關(guān)
系。
-
Entity
EJB（有學(xué)習(xí)曲線，沒有工具支持會相當(dāng)大）：我沒有對它進(jìn)行過深入的研究，但是從J2EE的概念上看，它是屬于O/RMapping概念的一種。它既是
一個事實上的工業(yè)標(biāo)準(zhǔn)而且又體現(xiàn)了EJB的容器管理特性。本身其實是很值得研究的，但是由于目前而言EJB3.0剛剛起步，而EJB2.0的開發(fā)也確實比
較麻煩，還有等等等等一系列的其他事情，我對它暫時處于觀望態(tài)度。
-
DataSet（比較簡單，看實現(xiàn)方式）：這是所有從PB和C++Builder年代走過來的人最喜歡的方式，它并沒有對關(guān)系操作進(jìn)行對象封裝，但是它卻
在對象級別對數(shù)據(jù)庫的操作進(jìn)行了比較好的封裝，相對而言它的使用難度跟SQLMapping
相當(dāng)，但是工作強(qiáng)度卻比SQLMapping要低。目前IBM和BEA提出那個CommonJ的持久層操作Service Data
Objects沒用過，不提什么意見，但是MS.NET的ADO.NET倒是用它做過項目，有點了解。MS的ADO.NET主要是通過DataSet經(jīng)由
DataAdapter進(jìn)行數(shù)據(jù)持久化操作，由DataSet記錄每一次對它的數(shù)據(jù)操作，在重新得到數(shù)據(jù)庫連接后，會經(jīng)由DataAdaptor通過分析
元信息（一般也是映射）和數(shù)據(jù)操作記錄來自動生成該執(zhí)行的SQL語句。DataSet本身可以跟XMLSchema等同（兩者可以相互轉(zhuǎn)化），所以在表現(xiàn)
XML數(shù)據(jù)的方面它是當(dāng)仁不讓的。我認(rèn)為DataSet的機(jī)制是ADO.NET的核心機(jī)制，也是微軟在應(yīng)用開發(fā)方面策略的所在。
評價：不用說也能清楚，直接JDBC操作的方式持久層和業(yè)務(wù)邏輯層耦合最嚴(yán)重，只要持久層有一點改變，業(yè)務(wù)邏輯層就得相應(yīng)的改變重新打包和部署，反之亦
然。事實上一個超過300個Class文件和500個JSP的中等項目中遍布JDBC直接操作的話，數(shù)據(jù)庫庫表和業(yè)務(wù)邏輯的每一處小的修改都是一場噩夢。
SQLMapping還算可以接受，事實證明SQLMapping是替換掉JDBC的最好方式，如果你現(xiàn)在還在執(zhí)意于使用直接使用JDBC的話，換
SQLMapping好了，效率不低，開發(fā)起來跟直接直接使用JDBC差距不大，
iBatis就不錯。
O/RMapping是一個重頭戲，它是目前唯一的一種用面向?qū)ο蟮姆绞浇鉀Q關(guān)系型數(shù)據(jù)庫持久化問題的方法（我覺得也是目標(biāo)明確的方法）。有趣的是，關(guān)系
型模型的范圍要比對象化模型寬泛，這樣就造成了，過去的系統(tǒng)設(shè)計中對對象化模型考慮的不夠，使得過去系統(tǒng)的中的數(shù)據(jù)存儲方式對O/RMapping實現(xiàn)不
利（這是事實）；還有就是很多數(shù)據(jù)為中心的業(yè)務(wù)處理（比如計算電費，報表數(shù)據(jù)處理），用對象化模型不太合適（注2），這種情況下，O/RMapping實
在是不能長袖善舞。
DataSet是一種萬金油式的對象化解決方案，處理小型的項目綽綽有余，處理大型的項目就有點力不從心了。萬金油式的解決方案最大的缺點就是高不成、低不就，雖然在使用上它是相對簡單的。我倒沒有說ADO.NET本身有問題，其實.NET也有O/RMapping啊。
綜上所述，我們可以得出結(jié)論。目前而言所有流行的持久層實現(xiàn)方式都有其優(yōu)點和缺點（技術(shù)辯證法）。作為商業(yè)化的企業(yè)級應(yīng)用而言，一個技術(shù)堅持到底的
路是走不通的（肯定會在技術(shù)的缺點上吃大苦頭）。我推薦至少要使用兩種以上的技術(shù)進(jìn)行持久層封裝（我推薦O/RMapping +
SQLMapping +
JDBC——實在是解決不了的問題再找JDBC），要采用務(wù)實的方式進(jìn)行技術(shù)選擇，而不要迷信哪一種技術(shù)，對于大型企業(yè)級開發(fā)而言，目前沒有銀彈。
注1：按我的話說是Dirty Work
注2：本身可重用性就不夠（各處的算法都有不同），但是對運行時效率的要求卻很高（有的時候甚至Java本身的效率都不足以達(dá)到要求，只能求之于其他語言）