#
基于JavaEE的分布式三層企業(yè)級應用的數(shù)據(jù)存取方式有很多種，比如關系型數(shù)據(jù)庫、普通文件、遠程服務等。但是數(shù)據(jù)的存取主要采用關系型數(shù)據(jù)庫，下面主要關注關系型數(shù)據(jù)庫的持久層開發(fā)方式。
開發(fā)方式大體以下幾種方式（括號內(nèi)為目前使用它的工作難度、強度，記住，我們討論的是動輒就上百個表、幾個業(yè)務小組聯(lián)合開發(fā)的企業(yè)級應用，所以工作強度的估計一點兒也沒有夸張）：
-
直接JDBC操作（簡單，小）：底層操作（注1）較多，弄不好就會造成業(yè)務邏輯層和持久層的高度耦合。
-
SQLMapping（比較簡單，一般）：把底層操作全部提取出來統(tǒng)一進行管理，本身并沒有對概念上進行什么革新。但是這種統(tǒng)一的處理在邏輯上其實屬于分而治之的邏輯，通過良好的對它的使用可以體現(xiàn)出松耦合實現(xiàn)持久層的要求，也相對比較便于管理和修改。
-
O/RMapping（有學習曲線，沒有工具支持會相當大）：存在的時間已經(jīng)很長，我認為它的最主要的作用是關系型數(shù)據(jù)庫的反設計——關系型數(shù)據(jù)庫的設計
就是要把現(xiàn)實中的對象和對象間關系設計成實體和實體間的關系映射。而O/RMapping恰好相反，它是把實體和實體間的關系映射還原回對象和對象間的關
系。
-
Entity
EJB（有學習曲線，沒有工具支持會相當大）：我沒有對它進行過深入的研究，但是從J2EE的概念上看，它是屬于O/RMapping概念的一種。它既是
一個事實上的工業(yè)標準而且又體現(xiàn)了EJB的容器管理特性。本身其實是很值得研究的，但是由于目前而言EJB3.0剛剛起步，而EJB2.0的開發(fā)也確實比
較麻煩，還有等等等等一系列的其他事情，我對它暫時處于觀望態(tài)度。
-
DataSet（比較簡單，看實現(xiàn)方式）：這是所有從PB和C++Builder年代走過來的人最喜歡的方式，它并沒有對關系操作進行對象封裝，但是它卻
在對象級別對數(shù)據(jù)庫的操作進行了比較好的封裝，相對而言它的使用難度跟SQLMapping
相當，但是工作強度卻比SQLMapping要低。目前IBM和BEA提出那個CommonJ的持久層操作Service Data
Objects沒用過，不提什么意見，但是MS.NET的ADO.NET倒是用它做過項目，有點了解。MS的ADO.NET主要是通過DataSet經(jīng)由
DataAdapter進行數(shù)據(jù)持久化操作，由DataSet記錄每一次對它的數(shù)據(jù)操作，在重新得到數(shù)據(jù)庫連接后，會經(jīng)由DataAdaptor通過分析
元信息（一般也是映射）和數(shù)據(jù)操作記錄來自動生成該執(zhí)行的SQL語句。DataSet本身可以跟XMLSchema等同（兩者可以相互轉化），所以在表現(xiàn)
XML數(shù)據(jù)的方面它是當仁不讓的。我認為DataSet的機制是ADO.NET的核心機制，也是微軟在應用開發(fā)方面策略的所在。
評價：不用說也能清楚，直接JDBC操作的方式持久層和業(yè)務邏輯層耦合最嚴重，只要持久層有一點改變，業(yè)務邏輯層就得相應的改變重新打包和部署，反之亦
然。事實上一個超過300個Class文件和500個JSP的中等項目中遍布JDBC直接操作的話，數(shù)據(jù)庫庫表和業(yè)務邏輯的每一處小的修改都是一場噩夢。
SQLMapping還算可以接受，事實證明SQLMapping是替換掉JDBC的最好方式，如果你現(xiàn)在還在執(zhí)意于使用直接使用JDBC的話，換
SQLMapping好了，效率不低，開發(fā)起來跟直接直接使用JDBC差距不大，
iBatis就不錯。
O/RMapping是一個重頭戲，它是目前唯一的一種用面向對象的方式解決關系型數(shù)據(jù)庫持久化問題的方法（我覺得也是目標明確的方法）。有趣的是，關系
型模型的范圍要比對象化模型寬泛，這樣就造成了，過去的系統(tǒng)設計中對對象化模型考慮的不夠，使得過去系統(tǒng)的中的數(shù)據(jù)存儲方式對O/RMapping實現(xiàn)不
利（這是事實）；還有就是很多數(shù)據(jù)為中心的業(yè)務處理（比如計算電費，報表數(shù)據(jù)處理），用對象化模型不太合適（注2），這種情況下，O/RMapping實
在是不能長袖善舞。
DataSet是一種萬金油式的對象化解決方案，處理小型的項目綽綽有余，處理大型的項目就有點力不從心了。萬金油式的解決方案最大的缺點就是高不成、低不就，雖然在使用上它是相對簡單的。我倒沒有說ADO.NET本身有問題，其實.NET也有O/RMapping啊。
綜上所述，我們可以得出結論。目前而言所有流行的持久層實現(xiàn)方式都有其優(yōu)點和缺點（技術辯證法）。作為商業(yè)化的企業(yè)級應用而言，一個技術堅持到底的
路是走不通的（肯定會在技術的缺點上吃大苦頭）。我推薦至少要使用兩種以上的技術進行持久層封裝（我推薦O/RMapping +
SQLMapping +
JDBC——實在是解決不了的問題再找JDBC），要采用務實的方式進行技術選擇，而不要迷信哪一種技術，對于大型企業(yè)級開發(fā)而言，目前沒有銀彈。
注1：按我的話說是Dirty Work
注2：本身可重用性就不夠（各處的算法都有不同），但是對運行時效率的要求卻很高（有的時候甚至Java本身的效率都不足以達到要求，只能求之于其他語言）
首先，需要知道什么是企業(yè)級應用。
企業(yè)級應用（enterprise applications），其實是一個軟件行業(yè)內(nèi)部通用的一個術語。如果解釋成通俗易懂的話來說，那就是一個企業(yè)范圍內(nèi)所使用的、基于計算機的穩(wěn)定的、安全的和高效的分布式信息管理系統(tǒng)。
對于企業(yè)級應用而言它的分布式有兩種形式：B/S結構和C/S結構。由于瀏覽器的功能日益強大、網(wǎng)頁技術的日益流行和應用服務器軟件和中間件產(chǎn)品的逐步成
熟，B/S結構的企業(yè)級應用已經(jīng)成為一種流行的趨勢，所以在下面的討論中所謂的企業(yè)級應用統(tǒng)一為基于B/S結構的分布式企業(yè)信息系統(tǒng)。
一般說來企業(yè)級應用都可以分為三層
持久層（Persistence Layer） 、
業(yè)務邏輯層（Business Logic Layer） 和
展現(xiàn)層（Presentation Layer ） 。
為什么要分這么幾個層次呢？
歸根結底主要原因只有一個——那就是提高軟件開發(fā)生產(chǎn)力，降低軟件開發(fā)成本，提高軟件產(chǎn)品質(zhì)量。
因為軟件公司也是資本公司，公司的主要目標是盈利而不是科技發(fā)展。所以，公司的技術架構的優(yōu)劣主要應該體現(xiàn)在公司的生產(chǎn)成本和產(chǎn)品的質(zhì)量上。
對于降低軟件產(chǎn)品的開發(fā)成本是軟件產(chǎn)品出現(xiàn)以來所有軟件公司所追求的目標。到目前為止，達到這個目標的方式有這么幾種：
- 把
軟件產(chǎn)品根據(jù)功能進行分解，分別開發(fā)：對于大的復雜系統(tǒng)，如果沒有很好的分解開發(fā)的話，其結果是不可想象的。現(xiàn)實中企業(yè)需要分開各個職能部門，它們的職責
和業(yè)務是不同的，這樣開發(fā)中需要根據(jù)業(yè)務進行任務分解，把大的系統(tǒng)分解成為小的業(yè)務系統(tǒng)。這樣才能夠實現(xiàn)系統(tǒng)開發(fā)過程中的并行開發(fā)，并且會培養(yǎng)業(yè)務專精人
員，提高開發(fā)的效率。
-
業(yè)務系統(tǒng)根據(jù)技術架構進行分層開發(fā)：分層的開發(fā)方式實現(xiàn)了人類對復雜事物的普遍處理方式——分而治之。通過把復雜的系統(tǒng)分解成為相對簡單的獨立系統(tǒng)，低耦
合的分解既可以實現(xiàn)開發(fā)人員的并行工作，又可以實現(xiàn)開發(fā)人員的任務分工。而且通過分層，對組件拼裝和流水化作業(yè)提供了理論和事實的基礎。
-
組件拼裝實現(xiàn)社會化分工：不必自己去創(chuàng)造輪子，直接付錢去買想要的輪子即可。這是從傳統(tǒng)的制造行業(yè)借鑒來的經(jīng)驗。J2EE得到的廣泛認同從實質(zhì)上體現(xiàn)了業(yè)界對這種方式的肯定。
-
過去經(jīng)驗的積累和積累資源的重復利用：重用一直是一個爭議比較大的東西，爭論的雙方各執(zhí)一詞，各有道理也各有大師助陣，但是那更多的是在理論上和技術層面
上。理論和技術上的爭論對商業(yè)軟件開發(fā)是無用的。因為商業(yè)化的軟件開發(fā)，最重要的是提供優(yōu)質(zhì)的產(chǎn)品和服務并且能夠最大可能的獲取利潤。所以，拋開具體實現(xiàn)
方式不談，我個人覺得公司過去經(jīng)驗的積累和積累資源的重復利用是有商業(yè)價值的。因為軟件公司必須得面對開發(fā)人員流動的問題，不管是升遷還是調(diào)動還是跳槽，
軟件公司總會面對業(yè)務專精人員的流失問題。業(yè)務專精人員的流失造成的成本是要計算在開發(fā)成本中的，所以怎樣以固化的形式積累業(yè)務人員的經(jīng)驗，和過去解決問
題的方案的可重復利用以及新員工職業(yè)培訓成本的降低在降低開發(fā)成本的方面是值得考慮的。
綜上所述，對于一個企業(yè)級應用框架（還有人開發(fā)企業(yè)級應用不用框架嗎？）而言，分層是提高開發(fā)效率、降低開發(fā)和培訓成本的最佳實踐方案之一。
但是，為什么要分為
持久層（Persistence Layer） 、
業(yè)務邏輯層（Business Logic Layer） 和
展現(xiàn)層（Presentation Layer ） 3層呢？
其實這三層不過就是從三個不同的視角去看這個企業(yè)信息系統(tǒng)罷了。從數(shù)據(jù)的角度看，企業(yè)信息系統(tǒng)不外乎就是對數(shù)據(jù)的存取。從功能的角度看，企業(yè)信息系統(tǒng)就是
對現(xiàn)實中的業(yè)務邏輯操作的信息化抽象而從用戶的角度上看，它是一個人機接口，它可以接受輸入并且會對所做的輸入做出相應的反應。這三層從底向上實現(xiàn)了底層
計算機數(shù)據(jù)和頂層人的業(yè)務操作的跨越，一般說來，從概念上講，所有的企業(yè)級應用框架都可以分成這三層，因為這三個視角是客觀的。但是這并不保證所有的企業(yè)
級應用都能保證這三個層之間不發(fā)生耦合。
“其安易持，其未兆易謀。其脆易泮，其微易散。為之於未有，治之於未亂。合
抱之木生於毫末。九層之臺起於累土。千里之行始於足下。為者敗之，執(zhí)者失之。
是以圣人無為故無敗，無執(zhí)故無失。民之從事常於幾成而敗之。慎終如始則無敗
事。是以圣人欲不欲，不貴難得之貨。學不學，復眾人之所過，以輔萬物之自然而
不敢為。”
——《道德經(jīng)》，老子
這是我的一個關于Java技術的Blog，為什么要寫這個Blog？
答案有四：
- 心得記錄：搞技術的人總是健忘（尤其是搞計算機的），分門別類寫成文章，強迫自己總結一下，增強記憶不說，還可以便于以后查找。
- 克服懶病：只想看而不寫總是對自己不好，立下一個愿望，爭取保持更新吧。
- 草稿收集：報告要寫，但是提交之后就如泥牛入海，杳無音訊了。我都不知道我因為換機器和重裝機器丟了多少草稿了（還是因為健忘和懶）。
- 拋磚引玉：我只有一些淺見，還望高手不吝賜教。
真心希望大家能夠共同交流，就算交個朋友吧。
這便算是個開篇。