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