學(xué)會(huì)選擇何種設(shè)計(jì)模式和構(gòu)架才可以開發(fā)出最好的企業(yè)程序
摘要文章中，列舉了Chris Richardson在POJOs in Action(2006年1月份出版)的例子，該例子舉了5個(gè)程序設(shè)計(jì)者在設(shè)計(jì)企業(yè)應(yīng)用程序中都會(huì)問自己的問題.
如果我們盲目的使用POJOs技術(shù)（plain-old Java objects）和輕量級(jí)構(gòu)架，那么我們?cè)谕ㄟ^EJB建立分布式企業(yè)級(jí)JAVA程序時(shí)就可能會(huì)出現(xiàn)錯(cuò)誤。每種技術(shù)都有它的強(qiáng)項(xiàng)和弱項(xiàng)，而根據(jù)實(shí)際情況選擇最合適的技術(shù)是最重要的。
這篇文章主要討論企業(yè)應(yīng)用程序的設(shè)計(jì)模式和輕量級(jí)構(gòu)架。為了讓你在程序中高效的使用這些設(shè)計(jì)模式和輕量級(jí)構(gòu)架，這里提供了一個(gè)決策構(gòu)架. 這個(gè)構(gòu)架包含了5個(gè)在設(shè)計(jì)程序或者是單獨(dú)用例的業(yè)務(wù)邏輯（business logic for an individual use-case）的過程中必須回答的問題（decision-making framework）。這里特意加上了設(shè)計(jì)方案和對(duì)這種決策的理解，這樣可以很大的提高你的軟件質(zhì)量。
在這篇文章中，你會(huì)看到對(duì)5種決策的簡(jiǎn)述，并且我會(huì)簡(jiǎn)單扼要的介紹每種設(shè)計(jì)決策的選項(xiàng)(options)和他們的優(yōu)缺點(diǎn)。
版權(quán)聲明：任何獲得Matrix授權(quán)的網(wǎng)站，轉(zhuǎn)載時(shí)請(qǐng)務(wù)必保留以下作者信息和鏈接作者:Chris Richardson；
tain198127(作者的blog:
http://blog.matrix.org.cn/page/tain198127)
原文:
http://www.javaworld.com/javaworld/jw-01-2006/jw-0130-pojo.html譯文:
http://www.matrix.org.cn/resource/article/44/44254_J2EE+design+decisions.html關(guān)鍵字:J2EE;design;decisions
業(yè)務(wù)邏輯和數(shù)據(jù)庫(kù)訪問決策這里有2種完全不同的方法來設(shè)計(jì)JAVA企業(yè)程序，其中一種選擇是采用標(biāo)準(zhǔn)EJB2實(shí)現(xiàn)途徑（approach）。我更愿意稱這種方法為重量級(jí)實(shí)現(xiàn)途徑，當(dāng)你使用重量級(jí)實(shí)現(xiàn)途徑時(shí)你需要用會(huì)話beans(session bean)和消息驅(qū)動(dòng) beans(message-driven bean)去實(shí)現(xiàn)業(yè)務(wù)邏輯。你也可以使用DAOs(data access object)或者實(shí)體bean去訪問業(yè)務(wù)邏輯
另外一種選擇是使用POJOs 和輕量級(jí)構(gòu)架，這種方式我稱為POJO實(shí)現(xiàn)途徑。當(dāng)使用POJOs實(shí)現(xiàn)途徑時(shí)，你的業(yè)務(wù)邏輯完全由POJO來實(shí)現(xiàn)。你可以使用持久型構(gòu)架又叫做對(duì)象/關(guān)系映射構(gòu)架（a.k.a=also know as ）例如Hibernate 或者 JDO來訪問數(shù)據(jù)庫(kù)，再用Spring AOP（面向?qū)用婢幊蹋﹣硖峁┢髽I(yè)服務(wù)，比如事務(wù)管理和安全。
EJB3由于融合了POJOs和其他一些輕量級(jí)概念，所以對(duì)兩者（指輕量級(jí)和重考鍛揪叮┑那植皇嗆芮宄?。举个例讬熏POJO中的實(shí)體bean既可以再EJB容器內(nèi)運(yùn)行，也可以再EJB容器外運(yùn)行，然而POJOs中的會(huì)話bean和消息驅(qū)動(dòng)bean仍然有重量級(jí)的行為，因?yàn)樗麄冎荒茉贓JB容器內(nèi)部運(yùn)行。所以，顯而易見的，EJB3既是重量級(jí)的又有POJO的特性。EJB3中的實(shí)體bean是輕量級(jí)實(shí)現(xiàn)途徑中的一部分。
在開發(fā)過程中，首要的是從各種各樣的設(shè)計(jì)中選擇到底采用重量級(jí)實(shí)現(xiàn)途徑還是采用POJO實(shí)現(xiàn)途徑。決策可以影響程序的幾個(gè)方面，包括業(yè)務(wù)邏輯結(jié)構(gòu)和數(shù)據(jù)訪問機(jī)制。為了幫助從兩種實(shí)現(xiàn)途徑中擇其一，來看這張典型的企業(yè)應(yīng)用程序結(jié)構(gòu)圖，結(jié)構(gòu)圖在圖示1中，而且在設(shè)計(jì)過程中就必須判斷到底使用那種策略。
Figure 1. A typical application architecture and the key business logic and database access design decisions.
程序由網(wǎng)絡(luò)基本表示層、業(yè)務(wù)層、持久層組成。網(wǎng)絡(luò)基本表示層負(fù)責(zé)HTTP請(qǐng)求和為一般的瀏覽器客戶端、XML和其他的胖體客戶端生成HTML，比如為Ajax基本客戶端生成HTML。業(yè)務(wù)層被表示層調(diào)用，用來實(shí)現(xiàn)程序業(yè)務(wù)邏輯。持久層被業(yè)務(wù)邏輯層用來訪問外部數(shù)據(jù)源，比如數(shù)據(jù)庫(kù)和其他程序。
表示層的設(shè)計(jì)不在本篇文章討論之內(nèi)，來看圖表的其他部分，我們需要決定業(yè)務(wù)層結(jié)構(gòu)的接口，這個(gè)接口是提供給表示層以及其他客戶端的。而且還需要決定怎樣訪問能供多個(gè)程序訪問的數(shù)據(jù)庫(kù)。我們還必須決定如何處理短期事務(wù)處理事務(wù)和長(zhǎng)期事務(wù)處理事務(wù)的并發(fā)問題。這些加起來一共有5種決策。每種決策都是要設(shè)計(jì)者來制定，為了能看懂演示圖（big picture）要求每個(gè)開發(fā)者也都了解這些策略。
這些決策直接決定程序業(yè)務(wù)和表示層設(shè)計(jì)的特點(diǎn)。當(dāng)然，還要決定一些其他很重要的決策。比如業(yè)務(wù)處理（transactions）、安全問題、緩存問題以及如何整合程序，但是關(guān)于這些問題通常在其他文獻(xiàn)中討論
在圖表1中顯示的五種決策，每種決策都有多種選擇。每種選擇根據(jù)它要解決的實(shí)際問題都有相應(yīng)的優(yōu)缺點(diǎn)。后續(xù)章節(jié)中，你會(huì)發(fā)現(xiàn)每種決策針對(duì)一個(gè)或多個(gè)領(lǐng)域時(shí)，在功能性、易開發(fā)性、可維護(hù)性和可用性方面有不同的平衡點(diǎn)。盡管我是POJO實(shí)現(xiàn)途徑的超級(jí)大FANS，但是仍然需要了解其優(yōu)缺點(diǎn)，以便于為你的程序做最好的選擇
下面我們來了解一下每種決策的大綱和其選項(xiàng)。
決策1：組織業(yè)務(wù)邏輯現(xiàn)在，很多的注意力都集中在某項(xiàng)技術(shù)的優(yōu)點(diǎn)和缺點(diǎn)，盡管這很重要，但是在本質(zhì)上你需要了解如何建構(gòu)你的業(yè)務(wù)邏輯。如果不考慮如何組織就去寫代碼是非常簡(jiǎn)單的。例如，為一個(gè)會(huì)話BEAN添加代碼要比在域模式(domain model.: An object model of the domain that incorporates both behavior and data.)中判斷應(yīng)該添加那種新特性要簡(jiǎn)單的多。理論上你仍然需要刻意的為你的軟件設(shè)計(jì)最合適的業(yè)務(wù)邏輯。畢竟我相信你有過修改別人垃圾結(jié)構(gòu)代碼的慘痛經(jīng)驗(yàn)
關(guān)鍵的決策是：到底應(yīng)該用面向?qū)ο蟮膶?shí)現(xiàn)途徑還是面向過程的實(shí)現(xiàn)途徑來實(shí)現(xiàn)你的程序。這個(gè)不是關(guān)于技術(shù)的決策，但是你技術(shù)上的決策可以潛在的約束你的業(yè)務(wù)邏輯的組織結(jié)構(gòu)。采用EJB2技術(shù)，有利于面向過程設(shè)計(jì)，然而POJOs和輕量級(jí)構(gòu)架可以讓你為特殊的程序選擇最好的實(shí)現(xiàn)途徑
采用過程式設(shè)計(jì)雖然我是一個(gè)面向?qū)ο髮?shí)現(xiàn)途徑（指前文的使用POJO和LIGHTFRAMEWORK）的倡導(dǎo)者，但是有些情況下面向?qū)ο髮?shí)現(xiàn)途徑有些大材小用，比如你只想實(shí)現(xiàn)一個(gè)非常簡(jiǎn)單的業(yè)務(wù)邏輯。而且，有時(shí)候，面向?qū)ο髮?shí)現(xiàn)途徑不太可行－—比如，你沒有持久層構(gòu)架來將你的對(duì)象映射到數(shù)據(jù)庫(kù)中，在這種情況下，更好的方法是編寫面向過程的代碼，而且采用Martin Fowler稱作事務(wù)腳本（Transaction Script）的設(shè)計(jì)模式，要比采用面向?qū)ο髮?shí)現(xiàn)途徑設(shè)計(jì)要好，因?yàn)槟阒恍枰獙懸粋€(gè)方法來調(diào)用事務(wù)處理腳本去處理表示層的請(qǐng)求。
采種這種實(shí)現(xiàn)途徑的一個(gè)很重要的特點(diǎn)是，用于實(shí)現(xiàn)某種行為的類和數(shù)據(jù)存儲(chǔ)區(qū)是分開的。在EJB2的應(yīng)用程序中，這種方式的業(yè)務(wù)邏輯和圖表2中的設(shè)計(jì)是非常相似的。這種設(shè)計(jì)的核心全都集中在EJB或者POJO的行為上，因?yàn)樗麄儗?shí)現(xiàn)了事務(wù)腳本，并且還操作那些 “啞”對(duì)象數(shù)據(jù)（因?yàn)樗麄冎粨碛泻苌俚男袨?，大部分都是?shù)據(jù)）。因?yàn)榇蟛糠值男袨槎技性谏倭康拇笮皖惿?，所以代碼會(huì)變的很難理解與維護(hù)。
Figure 2. The structure of a procedural design: large transaction script classes and many small data objects
這種設(shè)計(jì)具有高面向過程的特性，而且基本不依靠面向?qū)ο笳Z言的特性。如果你曾經(jīng)使用過C或者其他非面向?qū)ο笳Z言的話，你應(yīng)該用過這種設(shè)計(jì)模式。如果這種模式很適合你的設(shè)計(jì)的話，用這種模式設(shè)計(jì)也是一種不錯(cuò)的選擇。
這種直觀的過程式開發(fā)途徑，非常的誘人，因?yàn)槟阒恍枰獙懘a就好了，不用考慮如何組織你的類文件。但問題是，如果你的業(yè)務(wù)邏輯非常的復(fù)雜，那么你的代碼會(huì)變的噩夢(mèng)般的難以維護(hù)。所以，除非你要寫的程序非常的簡(jiǎn)單，否則你應(yīng)該用面向?qū)ο笤O(shè)計(jì)你的程序，而不要受面向過程的代碼的誘惑。
采用面向?qū)ο笤O(shè)計(jì)在面向?qū)ο笤O(shè)計(jì)中，業(yè)務(wù)邏輯是由對(duì)象模型構(gòu)成的，對(duì)象模型是由許多小類組成的關(guān)系網(wǎng)。這些類直接體現(xiàn)的是問題域的解決方法，如圖3所示，在這種模式中，有些類只有數(shù)據(jù)，有些類只有行為，但是大多數(shù)的則兩者都有，這是優(yōu)秀的類設(shè)計(jì)的一種特點(diǎn)。
Figure 3. The structure of a domain model: small classes that have state and behavior
面向?qū)ο笤O(shè)計(jì)有許多的好處，包括可以提高可維護(hù)性和可延展性。你可以用EJB2的實(shí)體bean來實(shí)現(xiàn)一個(gè)簡(jiǎn)單的對(duì)象模型。但是如果像要獲得更多的好處的話，必須要使用POJOs技術(shù)和輕量級(jí)持久層構(gòu)架——比如Hibernate和JDO技術(shù)。POJO可以讓你開發(fā)豐富的模型，這些模型可以擁有繼承和回調(diào)等特點(diǎn)。而輕量級(jí)持久層構(gòu)架可以讓你很簡(jiǎn)單的從對(duì)象模型映射到數(shù)據(jù)庫(kù)。
對(duì)象模型的另外一個(gè)名字是域模型，F(xiàn)owler稱這種由面向?qū)ο笸緩絹黹_發(fā)的業(yè)務(wù)邏輯叫做域模型設(shè)計(jì)模式。（就是類的設(shè)計(jì)是直接用來解決問題的，則這種設(shè)計(jì)模式叫做域模型設(shè)計(jì)模式）
表模型設(shè)計(jì)模式我曾經(jīng)一直用域模型和事務(wù)處理腳本模型設(shè)計(jì)應(yīng)用程序。但是有一次我聽說JAVA企業(yè)應(yīng)用程序可以用第三種途徑來實(shí)現(xiàn)，這種途徑就是Fowler所說的表模型設(shè)計(jì)模式。這種模式比事務(wù)處理腳本模式更加的結(jié)構(gòu)化，因?yàn)樗鼮閿?shù)據(jù)庫(kù)中的每個(gè)表都寫了一個(gè)類，而這個(gè)類中實(shí)現(xiàn)了所有對(duì)這個(gè)表的操作代碼，這個(gè)類就是表模型類。（我的解釋就是為每個(gè)表專門寫個(gè)類，對(duì)表的所有操作，全都由這個(gè)類中的方法實(shí)現(xiàn)，相當(dāng)于用一個(gè)類模擬的數(shù)據(jù)庫(kù)中的表）。和事務(wù)處理腳本模式相比，它將數(shù)據(jù)和行為分別封裝到了不同的類中，因?yàn)楸砟Ｐ皖惖膶?shí)例相當(dāng)于真實(shí)數(shù)據(jù)庫(kù)中的數(shù)據(jù)，這當(dāng)然要比單獨(dú)的一條記錄要好的多。最后，可維護(hù)性成了問題，然而表模型設(shè)計(jì)模式還是有一些好處的。
決策2:封裝業(yè)務(wù)邏輯前面幾章，我沒有提及如何組織業(yè)務(wù)邏輯。你必須決定業(yè)務(wù)邏輯有什么樣的接口。業(yè)務(wù)邏輯的接口由一些數(shù)據(jù)和方法組成，這些數(shù)據(jù)和方法由表示層來調(diào)用。在設(shè)計(jì)接口時(shí)重點(diǎn)需要考慮的是：應(yīng)該封裝哪些業(yè)務(wù)邏輯的操作，而哪些操作不應(yīng)該顯示給表示層。封裝接口可以提高程序的可維護(hù)性，因?yàn)橥ㄟ^隱藏業(yè)務(wù)邏輯的操作細(xì)節(jié)，可以實(shí)現(xiàn)修改業(yè)務(wù)邏輯而不影響表示層。缺點(diǎn)是，你必須為封裝業(yè)務(wù)邏輯而特意的寫很多的代碼。
你還需要考慮其他重要的問題，比如如何處理事務(wù)處理，安全，和遠(yuǎn)程調(diào)用問題。通常這些也是業(yè)務(wù)邏輯接口要負(fù)責(zé)的問題。為了保證數(shù)據(jù)的連貫性，業(yè)務(wù)層的接口必須保證每個(gè)事務(wù)處理中的調(diào)用都能執(zhí)行。同樣，也要驗(yàn)證調(diào)用者是否有權(quán)限調(diào)用業(yè)務(wù)方法。業(yè)務(wù)層接口還要負(fù)責(zé)處理一些遠(yuǎn)程客戶端的問題。
來考慮一下選項(xiàng)。
EJB session façade經(jīng)典的J2EE解決方案是：用EJB來封裝業(yè)務(wù)邏輯－基本的session facade。EJB容器提供事務(wù)處理管理，安全，分布式事務(wù)處理和遠(yuǎn)程訪問。Facade方式可以通過封裝業(yè)務(wù)邏輯來提高程序可維護(hù)性。粗糙型（Coarse-grained） API通過減少表示層對(duì)業(yè)務(wù)層的訪問次數(shù)，而提高性能（因?yàn)樗鼘?duì)各個(gè)業(yè)務(wù)流程的處理再封裝了一次，所以對(duì)底層的業(yè)務(wù)流程來說，它的API是比較粗糙的，這里也許翻譯的不好。請(qǐng)大家見諒）。因?yàn)闇p少調(diào)用的次數(shù)，可以減少對(duì)數(shù)據(jù)庫(kù)事務(wù)處理的次數(shù)，還可以提高對(duì)象在緩沖區(qū)的機(jī)會(huì)。如果表示層通過遠(yuǎn)程訪問業(yè)務(wù)層，則這種API還可以減少網(wǎng)絡(luò)負(fù)擔(dān)。圖表4給出了一個(gè)EJB－based session facade的例子。
Figure 4. Encapsulating the business logic with an EJB session façade
在這種設(shè)計(jì)模式中，表示層也許是通過遠(yuǎn)程來調(diào)用facade（相當(dāng)于session的一個(gè)高級(jí)接口）,EJB容器從facade中得到這個(gè)調(diào)用，并驗(yàn)證調(diào)用者的權(quán)限，然后開始一個(gè)業(yè)務(wù)處理。這個(gè)時(shí)候facade調(diào)用底層的業(yè)務(wù)對(duì)象，而這些業(yè)務(wù)對(duì)象負(fù)責(zé)實(shí)現(xiàn)具體的業(yè)務(wù)邏輯。等Facade返回后，EJB容器提交業(yè)務(wù)處理或者讓該業(yè)務(wù)處理循環(huán)等待。
不幸的是，使用EJB session facade有一些嚴(yán)重的缺點(diǎn)。比如，EJB的會(huì)話bean只能在EJB容器中運(yùn)行，這樣就托慢了開發(fā)和測(cè)試周期。另外，如果用EJB2，則用來向表示層傳輸數(shù)據(jù)的數(shù)據(jù)傳輸對(duì)象的開發(fā)和維護(hù)就會(huì)變的很枯燥而且曠日持久。
POJO facade對(duì)于許多程序來說，更好的實(shí)現(xiàn)途徑是用POJO facade和AOP協(xié)作。比如負(fù)責(zé)管理事務(wù)處理、表示層的連接和安全問題的Spring 構(gòu)架。POJO facade對(duì)業(yè)務(wù)層的封裝風(fēng)格和EJB facade很相似，通常也可以用一樣的公共方法。而POJO和EJB關(guān)鍵區(qū)別是用POJO代替了EJB，用AOP提供的服務(wù)（例如業(yè)務(wù)處理管理和安全機(jī)制）替代了EJB容器。表5中，顯示了用POJO facade的例子。
Figure 5. Encapsulating the business logic with a POJO façade
表示層調(diào)用POJO facade, POJO facade 調(diào)用業(yè)務(wù)對(duì)象。和EJB容器截獲EJB facade方式一樣，AOP通過“攔截機(jī)”來截獲POJO facade，并驗(yàn)證調(diào)用者的權(quán)限，然后開始提交業(yè)務(wù)處理或讓該業(yè)務(wù)循環(huán)等待。
通過在應(yīng)用程序服務(wù)器外部開發(fā)和調(diào)試業(yè)務(wù)邏輯，對(duì)POJO facade的開發(fā)可以變的很簡(jiǎn)單，同時(shí)還可以獲得許多EJB中會(huì)話Bean的好處，比如聲明事務(wù)處理和安全。關(guān)鍵是，你可以少寫點(diǎn)代碼。你可以避免寫數(shù)據(jù)傳輸對(duì)象類，因?yàn)镻OJO facade可以將對(duì)象域直接反饋給表示層；你可以使用依賴注射的方式來將應(yīng)用程序組裝起來，而不用在為JNDI寫查找代碼了。
然而，有些時(shí)候不能那用POJO facade，比如它不能參與到遠(yuǎn)程客戶端建立的分布式事務(wù)處理。
暴露模型域模式使用facade的一個(gè)缺點(diǎn)是你必須寫額外的代碼，而且負(fù)責(zé)將對(duì)象域返回給表示層的代碼很容易出錯(cuò)。如果表示層設(shè)法調(diào)用某個(gè)對(duì)象，而業(yè)務(wù)層卻沒有提供該對(duì)象，也會(huì)增加runtime error出現(xiàn)的機(jī)會(huì)。如果你用JDO , Hibernate或者EJB3，則可以避免這種問題，方法是：將模型域（session區(qū)域）暴露給表示層，再將相應(yīng)的對(duì)象域（存儲(chǔ)對(duì)象的區(qū)域）返回給表示層，根據(jù)表示層在對(duì)象域之間的操作關(guān)系，持久層來導(dǎo)入相應(yīng)的對(duì)象。（也就是把session區(qū)域給表示層，然后分析它需要的對(duì)象，再讓持久層去加載這些對(duì)象）這就是所謂的lazy loading 技術(shù)。圖表6中顯示了表示層自由的訪問對(duì)象域的設(shè)計(jì)圖。
Figure 6. Using an exposed domain model
在圖表6的設(shè)計(jì)中，表示層不通過facade而直接調(diào)用域?qū)ο?，Spring AOP仍然提供服務(wù)，例如事務(wù)處理管理和安全。
用這種實(shí)現(xiàn)途徑的一個(gè)重要的好處是，業(yè)務(wù)層不需要知道哪些對(duì)象需要調(diào)用，也不用知道那些需要返回給表示層。盡管這挺起來很簡(jiǎn)單，但是你會(huì)發(fā)現(xiàn)一些缺點(diǎn)。這會(huì)增加表示層的復(fù)雜度，因?yàn)槟惚仨毺幚韺?duì)數(shù)據(jù)庫(kù)的連接。而且在基于Web的應(yīng)用程序中，事務(wù)處理管理也要非常小心，因?yàn)樵诒硎緦訉?shù)據(jù)反饋給瀏覽器之前，事務(wù)處理的數(shù)據(jù)必須保持正確。
決策3：訪問數(shù)據(jù)庫(kù)無論你怎樣對(duì)業(yè)務(wù)邏輯怎樣的組織和封裝，最終你還是要從數(shù)據(jù)庫(kù)中取數(shù)據(jù)出來。在經(jīng)典的J2EE應(yīng)用程序中，你有2個(gè)選擇：JDBC——這個(gè)需要很多的底層代碼；或者實(shí)體Bean——這個(gè)用起來非常困難，而且缺少重要特征。相比來說，使用輕量級(jí)構(gòu)架令人高興的事情之一就是：你有一些新的而且更有力的方法去訪問數(shù)據(jù)庫(kù)，而且這種方法可以顯著的減少訪問數(shù)據(jù)庫(kù)的代碼。讓咱們來進(jìn)一步研究
直接用JDBC會(huì)有什么問題最近突然出現(xiàn)了對(duì)象/關(guān)系 映射構(gòu)架（比如JDO和Hibernate） 和SQL映射構(gòu)架（比如iBATIS）這些不是憑空出現(xiàn)的。相反，他們是在JAVA 聯(lián)盟在JDBC屢造挫折之后才出現(xiàn)的。為了了解新構(gòu)架出現(xiàn)的原因，這里咱們回顧一下直接使用JDBC會(huì)出現(xiàn)的問題。在許多程序中直接使用JDBC不是一個(gè)好的選擇，主要有以下三個(gè)原因：
· 開發(fā)和維護(hù)SQL非常的困難而且耗費(fèi)時(shí)間——一些開發(fā)者發(fā)現(xiàn)要寫龐大而且復(fù)雜的SQL語句非常的困難。反映數(shù)據(jù)庫(kù)變化的SQL語句會(huì)變得非常耗時(shí)。你必須小心的考慮犧牲可維護(hù)性是否值得。
· 用SQL會(huì)使移植性變的很差——因?yàn)樾枰獢?shù)據(jù)庫(kù)的特殊SQL語句。如果一個(gè)程序和多個(gè)數(shù)據(jù)庫(kù)有關(guān)系，那么你就要寫多個(gè)版本的SQL語句，這使得可維護(hù)性變變成噩夢(mèng)。
· 直接寫JDBC代碼要會(huì)非常耗時(shí)，而且容易出錯(cuò)。你必須寫很多的樣板代碼去獲得連接，創(chuàng)建和初始化適當(dāng)?shù)穆暶?，還要用精確的聲明去清理連接。而且你還要寫代碼去將JAVA 對(duì)象映射到SQL聲明。由于要無奈的去寫，
JDBC代碼很容易出錯(cuò)。
如果你的程序必須直接運(yùn)行SQL語句的話，那前面兩個(gè)問題是無法避免的。有時(shí)候?yàn)榱双@得好的性能，必須要全力的寫SQL語句，包括供應(yīng)商提供的那些特殊東西。由于許多業(yè)務(wù)上的原因，持久層可能會(huì)產(chǎn)生混亂的SQL語句，為了防止這種情況，DBA可能要求你的程序來完全控制SQL語句的執(zhí)行。通常，團(tuán)隊(duì)買進(jìn)的關(guān)系型數(shù)據(jù)庫(kù)過于龐大，以至于應(yīng)用程序工作時(shí)會(huì)出現(xiàn)一些和數(shù)據(jù)庫(kù)有關(guān)的瑣碎事務(wù)。根據(jù)”iBATIS in Action”的作者說這里會(huì)有一種情況出現(xiàn)：“數(shù)據(jù)庫(kù)或者SQL語句本身存在的時(shí)間比程序代碼存在的時(shí)間還要長(zhǎng)，或者同一段SQL語句或數(shù)據(jù)庫(kù)有多個(gè)程序的版本。有些情況下，程序已經(jīng)用另外一種語言重寫了，但是SQL語句和數(shù)據(jù)庫(kù)卻沒有太大的改變。” 如果直接使用SQL弄的你筋疲力盡，那么很幸運(yùn)，這里有一種直接執(zhí)行SQL語句的構(gòu)架，它可比用JDBC要容易多了。當(dāng)然了，這就是iBATIS.
使用 iBATIS我開發(fā)過的所有企業(yè)JAVA應(yīng)用程序，都是直接執(zhí)行SQL語句的。早期的程序是執(zhí)行特定的SQL語句的，后來是用持久層構(gòu)架再用少量的SQL語句構(gòu)成的。一開始我直接用JDBC來執(zhí)行SQL語句，但是后來，我經(jīng)常寫一些小的構(gòu)架去完成JDBC中那些比較無聊的部分。我也用過一段Spring的JDBC類，這些類除去了JDBC中的許多樣板代碼。但是無論是我自己寫的構(gòu)架還是使用Spring的類，在Java類映射到SQL語句的時(shí)候都會(huì)存在問題，這就是我為什么那么高興的加入iTATIS 那邊的原因了。
iBATIS 不僅將應(yīng)用程序完全的與“數(shù)據(jù)庫(kù)連接”、具體的SQL語句隔絕開來，更實(shí)現(xiàn)了通過XML描述文檔來將JavaBean 映射到SQL語句。它用Java bean 內(nèi)省機(jī)制來將“道具bean（bean properties）”映射為相應(yīng)的數(shù)據(jù)庫(kù)語句占位符，而且它可以將ResultSet后的結(jié)果構(gòu)造為bean。它還可以通過數(shù)據(jù)庫(kù)生成主鍵，自動(dòng)加載相關(guān)的對(duì)象、實(shí)現(xiàn)緩存和lazy loading。這樣，iBATIS 就除去了許多執(zhí)行SQL語句帶來的苦差。通過編輯XML描述文檔和調(diào)用少量的iBATIS的API，代替了寫大量的JDBC底層代碼。
使用持久層框架當(dāng)然，iBATIS不能實(shí)現(xiàn)高層開發(fā)和維護(hù)SQL語句，而且缺乏可移植性。為了避免這類問題，你需要用到持久層框架。持久層框架可以將對(duì)象域映射到數(shù)據(jù)庫(kù)中。它提供了創(chuàng)建，查找，刪除對(duì)象的API函數(shù)。當(dāng)程序要控制對(duì)象時(shí)它可以自動(dòng)的加載相應(yīng)的對(duì)象，還可以在事務(wù)處理結(jié)束時(shí)自動(dòng)更新數(shù)據(jù)庫(kù)。持久層框架通過對(duì)象/關(guān)系映射機(jī)制可以自動(dòng)的生成SQL語句，對(duì)象/關(guān)系映射機(jī)制用XML文檔定義了怎樣將類映射為表，怎樣將數(shù)據(jù)映射為列（column）和關(guān)系是怎樣被映射為外鍵與連接表的。
在持久層構(gòu)架上EJB也有它的短處：實(shí)體bean。EJB2的實(shí)體bean有很多的不足，而且開發(fā)和測(cè)試它會(huì)變得非常的枯燥。最后，很少用EJB2的實(shí)體bean了。在EJB3中會(huì)說明那些問題。
兩種最有流行的輕量級(jí)持久層構(gòu)架是JDO和Hibernate，前者是Sun的標(biāo)準(zhǔn)框架，后者是開源工程。兩種框架都可以為POJO類提供持久層事務(wù)處理。你可以用POJO類來開發(fā)和測(cè)試你的業(yè)務(wù)邏輯，而不用擔(dān)心持久層的問題，這個(gè)時(shí)候它會(huì)將類映射到數(shù)據(jù)庫(kù)中的schema。另外，他們兩個(gè)都可以在服務(wù)器程序外部或者內(nèi)部，這樣可以進(jìn)一步降低開發(fā)難度。用Hibernate和JDO來進(jìn)行開發(fā)比用老的EJB2的實(shí)體bean要舒服的多。
除了要決定怎樣訪問數(shù)據(jù)庫(kù)外，還要決定如何處理數(shù)據(jù)庫(kù)的并行處理問題。下面來看一下，為什么并行處理問題那么重要，同時(shí)看一下可實(shí)現(xiàn)的選項(xiàng)
決策4：處理數(shù)據(jù)庫(kù)事務(wù)處理的并行問題差不多所有的企業(yè)應(yīng)用程序都需要多用戶和多個(gè)后臺(tái)進(jìn)程并行的更新數(shù)據(jù)庫(kù)。2個(gè)數(shù)據(jù)庫(kù) 處理事務(wù)同時(shí)訪問同時(shí)訪問同一個(gè)數(shù)據(jù)是很正常的，但是這種情況很可能引起數(shù)據(jù)庫(kù)中的數(shù)據(jù)不一致或者引起應(yīng)用程序的不正常。由于大部分的應(yīng)用程序都需要處理多個(gè)處理事務(wù)并行訪問同一個(gè)數(shù)據(jù)，則它可以影響到業(yè)務(wù)和持久層的設(shè)計(jì)。
無論你是使用EJB還是輕量級(jí)構(gòu)架，你的程序必須可以并行訪問共享數(shù)據(jù)。EJB2要求使用供應(yīng)商提供的特殊擴(kuò)充接口來實(shí)現(xiàn)并行，然而與此不同的是，JDO和Hibernate可以直接支持大部分并行機(jī)制。更重要的是，使用JDO和Hibernate不僅只配置簡(jiǎn)單，而且只需要少量的代碼就可以實(shí)現(xiàn)了。
在這樣主要介紹幾種“并行更新數(shù)據(jù)庫(kù)處理事務(wù)”的選項(xiàng)的概要，這些事務(wù)處理和用戶的輸入無關(guān)。下一章，我主要介紹一下如何在應(yīng)用程序級(jí)長(zhǎng)時(shí)間的并行更新數(shù)據(jù)庫(kù)處理事務(wù)，這種處理事務(wù)會(huì)與用戶輸入有關(guān)，而且是由一系列的數(shù)據(jù)庫(kù)事務(wù)處理組成的。
獨(dú)立數(shù)據(jù)庫(kù)事務(wù)有時(shí)候?qū)蚕頂?shù)據(jù)的并行訪問可以簡(jiǎn)單的依靠數(shù)據(jù)庫(kù)本身來實(shí)現(xiàn)，數(shù)據(jù)庫(kù)可以設(shè)置為執(zhí)行孤立的數(shù)據(jù)——這只是對(duì)數(shù)據(jù)庫(kù)而言。如果你對(duì)這種概念不熟悉也不要擔(dān)心，你只要記?。喝绻麘?yīng)用程序使用完全的孤立事務(wù)方式，那么同時(shí)執(zhí)行2個(gè)事務(wù)的結(jié)果和一個(gè)接一個(gè)的執(zhí)行是一樣的。（也就是說，如果你用孤立事務(wù)的方式來訪問數(shù)據(jù)庫(kù)的話，你同時(shí)執(zhí)行2個(gè)事務(wù)，就會(huì)變成一個(gè)接一個(gè)的串行執(zhí)行了。）
這種方法也許聽起來非常的簡(jiǎn)單，但問題是這種處理方式有時(shí)候會(huì)降低性能，因?yàn)槿绾螌?shí)現(xiàn)對(duì)事務(wù)的孤立是由數(shù)據(jù)庫(kù)來決定的。為了這個(gè)原因，許多應(yīng)用程序都避免使用它，而采用optimistic或者pessimistic 所鎖，這會(huì)在下面講到。
開放式鎖定并行更新數(shù)據(jù)的一種途徑是用開放式鎖定。開放式鎖定工作原理是通過應(yīng)用程序來檢查數(shù)據(jù)是否被更新（被其他事務(wù)修改造成的）而實(shí)現(xiàn)的。一種更普通的實(shí)現(xiàn)開放式鎖定的方法是在每個(gè)表中添加一個(gè)“版本列”（version column），對(duì)每個(gè)表而言，程序每次改變其中一行的時(shí)候都會(huì)更新這個(gè)“版本列”。每個(gè)UPDATE語句中的WHERE語句會(huì)根據(jù)上次查詢的結(jié)果判斷這個(gè)版本號(hào)是不是被更改了。在事務(wù)訪問數(shù)據(jù)庫(kù)中的數(shù)據(jù)時(shí)，程序中可以用PreparedStatement.executeUpadte()這個(gè)函數(shù)的返回值來檢查行的個(gè)數(shù)，從而判斷是否要繼續(xù)執(zhí)行UPDATE語句。如果數(shù)據(jù)中的行已經(jīng)被其他的事務(wù)更新或者刪除了，那么程序會(huì)讓該事務(wù)從新訪問數(shù)據(jù)庫(kù)。
用開放式鎖定機(jī)制來鎖定那些直接執(zhí)行SQL語句的應(yīng)用程序是非常簡(jiǎn)單的。但是，用持久層構(gòu)架（比如JDO和Hibernate）實(shí)現(xiàn)更容易，因?yàn)樗麄円呀?jīng)提供了開放式鎖定機(jī)制——在配置選項(xiàng)中。一旦在配置選項(xiàng)中，選中了這種方式，持久層構(gòu)架會(huì)自動(dòng)的生成SQL的UPDATE語句來完成版本檢查的任務(wù)。開放式鎖定的名字來源于一種假設(shè)的情況，在這種情況下：并發(fā)更新的機(jī)會(huì)非常少，而且程序只能檢測(cè)、覆蓋這些數(shù)據(jù)而不能防止這種事情的發(fā)生。另外一種可選的途徑是用保守式鎖定，使用他的假設(shè)條件是：并發(fā)更新肯定會(huì)發(fā)生，而且必須被禁止。
保守式鎖定對(duì)于開放式鎖定來說，另外一種途徑是使用保守式鎖定。當(dāng)一個(gè)事務(wù)讀取某些行的數(shù)據(jù)時(shí)，他會(huì)對(duì)這些數(shù)據(jù)加鎖，這樣就防止其他的事務(wù)訪問這些數(shù)據(jù)了。具體的實(shí)現(xiàn)是需要數(shù)據(jù)庫(kù)支持的，然而不幸的是，不是所有的數(shù)據(jù)庫(kù)都支持保守式鎖定。如果你的數(shù)據(jù)庫(kù)支持話，那么你的應(yīng)用程序直接執(zhí)行SQL語句來實(shí)現(xiàn)保守式鎖定將非常容易。但是，可能你已經(jīng)猜到了，在程序中用JDO或者Hibernate來實(shí)現(xiàn)保守式鎖定更容易，JDO以配置選項(xiàng)的方式提供了保守式鎖定，而Hibernage提供了簡(jiǎn)單的API實(shí)現(xiàn)鎖定對(duì)象。
除了可以處理單個(gè)數(shù)據(jù)庫(kù)事務(wù)并行問題，常常你還需要處理多數(shù)據(jù)庫(kù)事務(wù)的并行問題。
決策5：在長(zhǎng)事務(wù)下處理并發(fā)訪問獨(dú)立事務(wù)、開放式鎖定、和保守式鎖定只能用在單個(gè)數(shù)據(jù)庫(kù)事務(wù)上的，然而，許多的程序需要 長(zhǎng)時(shí)間的 在多個(gè)數(shù)據(jù)庫(kù)事務(wù)之間 讀取或者更新 共享數(shù)據(jù)。比如，有一種情況描述的是 怎樣實(shí)現(xiàn) 用戶編輯命令，這和很多的進(jìn)程有關(guān)，這些進(jìn)程可能會(huì)運(yùn)行 很長(zhǎng)的時(shí)間，而且它由 多個(gè)數(shù)據(jù)庫(kù)事務(wù)組成。因?yàn)閿?shù)據(jù)可能會(huì)被 一個(gè)數(shù)據(jù)庫(kù)事務(wù) 讀取，而又被 另外一個(gè)數(shù)據(jù)庫(kù)事務(wù) 修改了，那么程序必須對(duì) 共享數(shù)據(jù)的并發(fā)訪問 進(jìn)行不同的處理。這樣就必須使用 開放式鎖定設(shè)計(jì)模式或 者保守是鎖定設(shè)計(jì)模式，關(guān)于這兩種模式會(huì)在Fowler的 Patterns of Enterprise Application Architecutre中詳細(xì)介紹。
開放式脫機(jī)鎖定模式一種選擇是開放式鎖定機(jī)制的擴(kuò)展，它會(huì)從第一次讀取數(shù)據(jù)開始，在編輯進(jìn)程執(zhí)行后檢查數(shù)據(jù)是否已經(jīng)被修改了。例如，你可以在數(shù)據(jù)庫(kù)的共享數(shù)據(jù)的表中使用版本號(hào)來實(shí)現(xiàn)。在編輯進(jìn)程開始的時(shí)候，程序?qū)姹咎?hào)存儲(chǔ)到會(huì)話狀態(tài)中，然后每次用戶要存儲(chǔ)數(shù)據(jù)時(shí)，應(yīng)用程序都要進(jìn)行檢查，保證數(shù)據(jù)庫(kù)中的版本號(hào)和會(huì)話狀態(tài)中的版本號(hào)一致。
因?yàn)殚_放式脫機(jī)鎖定模式只有在用戶進(jìn)行保存修改過的數(shù)據(jù)時(shí)才可以檢測(cè)，所以它只有在不成為客戶的累贅的時(shí)候，才可以很好的運(yùn)行。但如果情況是：客戶必須要撤銷幾個(gè)操作的話，那么就會(huì)因?yàn)檫@種鎖定模式而非?？鄲溃敲锤玫囊环N選擇是用保守式脫機(jī)鎖定。
保守式脫機(jī)鎖定模式在編輯進(jìn)程開始時(shí)，保守式脫機(jī)鎖定方式通過鎖定 共享數(shù)據(jù)，來解決 多個(gè)數(shù)據(jù)庫(kù)事務(wù) 同時(shí)更新共享數(shù)據(jù)的問題，這樣，這個(gè)編輯進(jìn)程就可以防止 其他的用戶來修改數(shù)據(jù)了。這種方式和保守式鎖定機(jī)制一開始描述的很類似，但它是靠程序來實(shí)現(xiàn)的，而不是數(shù)據(jù)庫(kù)。因?yàn)橥粫r(shí)間內(nèi)，只有有權(quán)利編輯共享數(shù)據(jù)的用戶，才有權(quán)利去保存這些修改。
