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