6、 數據訪問對象
數據訪問對象(data access object，DAO)模式將數據訪問邏輯抽象為特殊的資源，也就是說將系統資源的接口從其底層訪問機制中隔離出來；通過將數據訪問的調用打包，數據訪問對象可以促進對于不同數據庫類型和模式的數據訪問。
這種模式出現的背景在于數據訪問的邏輯極大程度上取決于數據存儲的格式，比如說關系型數據庫、面向對象數據庫、磁盤文件等。
目前大部分的J2EE應用程序都需要在一定程度上使用可持久性的數據，而實現持久性數據的方法因應用程序不同而異，并且訪問不同存儲格式數據的應用程序接口(API)也有著顯著的差別；有的時候，應用程序還會訪問存儲在不同操作平臺上的數據，這使得問題更為復雜，通常，應用程序會使用共享的分布式組件，如實體bean來表達持久性數據。應用程序可以使用bean管理的持久性實體bean，而在實體bean中植人數據訪問邏輯，或者使用容器管理的持久性實體bean，從而使容器管理所有的事務和持久性細節；而如果應用程序對于數據訪問的需求十分簡單的話，也可以采用會話bean或Servlet直接訪問持久性存儲來讀取和修改數據。
一些應用程序可以使用JDBC應用程序接口來訪問關系數據庫中的數據，JDBC負責一般的持久性數據訪問和管理，在J2EE應用程序中，JDBC中可以嵌入SQL語句，用以訪問關系型數據庫，當然根據數據庫類型的不同，SQL語句的詞法和語法也會有所不同；需要說明的是，當數據存儲格式不同的時候，數據訪問邏輯的區別就更加明顯了，例如關系型數據庫、面向對象數據庫和磁盤文件，各自數據的訪問邏輯各有千秋，這樣一來就造成了程序代碼和數據訪問代碼之間的依賴關系；當程序組件，即實體bean、會話bean或servlet、JSP等需要訪問數據源時，它們會使用正確的應用程序接口來得到連接并管理數據源，但這樣也會造成這些組件與數據源物理實現之間的依賴關系，從而使得應用程序很難從一個數據存儲實體移植到另一個數據存儲實體中去；當數據源的物理實現變化的時候，應用程序也必須相應地加以改變。
基于以上所討論的問題，開發人員開始采用數據訪問對象的方法。數據訪問對象實際上就是包含對于所有數據訪問邏輯的對象，并管理著對于數據源的連接，根據數據源的不同，數據訪問對象實現了不同的訪問機制，這里所說的數據源可以是持久性存儲介質，如關系型數據庫，也可以是外部服務，如B2B的數據交換；不僅是用戶，而且包括應用系統中的其他組件，也可以使用數據訪問對象所提供的數據訪問接口，數據訪問對象將數據源的物理實現細節與其用戶完全分離開來，并且在底層數據源變化的時候，數據訪問對象向用戶提供的接口是不會變化的；這種方法使應用系統使用數據訪問對象時可以適應多種數據存儲介質，總之，數據訪問對象就是系統組件和數據源中間的適配器。
圖8中的類圖表示了數據訪問對象設計模式的參與對象和之間的調用關系，圖9是這種設計模式的序列圖。
.files/image016.jpg)
圖8 數據訪問對象類圖
.files/image018.jpg)
圖9 數據訪問對象序列圖
對于圖9序列圖中的組件加以解釋如下：
(1)業務對象(Business Object)。表示數據的用戶，它需要對于數據的訪問，一個業務對象可以用會話bean、實體bean或是其他Java程序來實現。
(2)數據訪問對象(Data Access Object)。數據訪問對象是這種模式中的主題，它提供了底層數據訪問的對象，并將其提供給業務對象以使得后者能夠透明地訪問數據源；同時業務對象也將數據的加載和存儲操作移交給數據訪問對象處理。
(3)數據源(Data source)。這里指的是數據源的物理實現，這個數據源可以是一個數據庫，包括關系型數據庫、面向對象數據庫或文件系統。
(4)傳輸對象(Transfer Object)。這里的傳輸對象指的是數據載體。數據訪問對象可以使用傳輸對象來向用戶返回數據，而數據訪問對象同樣可以從用戶那里得到傳輸對象來對數據源中的數據進行更新。
下面給出幾種實現數據訪問對象設計模式的方法。
(1)自動數據訪問對象代碼的生成
既然每一個業務對象都對應于一個數據訪問對象，那么開發人員就可以建立業務對象、數據訪問對象和底層實現的關系；一旦這種關系建立起來，開發人員就可以為所有的數據訪問對象編寫特殊的代碼生成工具。
生成數據訪問對象的信息通常存儲在一個開發人員定義的描述文件中，如果對于數據訪問對象的要求過于復雜，開發人員可以考慮使用第三方工具來為關系型數據庫提供對象對關系的映射。這些工具通常是一些GUI程序，可以用來將業務對象映射為持久性的存儲對象，并定義中間運作的數據訪問對象，在映射完成的時候，這些工具可以自動地生成代碼，并提供一些相應的功能，如緩存結果、緩存查詢、與應用服務器整合、與第三方產品整合等。
(2)數據訪問對象代理(Factory for Data Access Objects)
當底層的數據存儲不會輕易改變的時候，開發人員可以采取這種方法來實現相應的，數據訪問對象，圖10是這種方法的類圖。
.files/image020.jpg)
圖10 使用DAO代理類圖
當底層的數據存儲可能會變化的時候，開發人員可以采用抽象代理的方法來實現數據訪問對象；抽象代理的方法會創建一些虛擬的數據訪問對象代理和各種類型的實際數據訪問對象代理，每種對象對應一種持久性存儲介質的實現，一旦組件得到這些代理，就可以利用來創建需要使用的數據訪問對象。
圖11給出了這種情況的類圖。該類圖表示了一個基礎的數據訪問對象代理，它是一個抽象類，被其他一些實際的數據訪問對象代理繼承以支持特定的數據訪問函數；用戶可以得到一個實際的數據訪問對象，并利用它來創建需要的數據訪問對象而訪問相關的數據，每一個實際的數據訪問對象都負責建立對于數據源的連接，并得到和管理所支持的業務數據。
.files/image022.jpg)
圖11 抽象代理使用DAO
下圖12是這種情況下的序列圖。
.files/image024.jpg)
圖12抽象代理使用DAO序列圖
這種設計模式的優勢：
-
透明性好。業務對象可以在不知道數據源實現細節的情況下訪問數據。由于一切數據訪問細節被數據訪問對象所隱藏，所以這種訪問過程是透明的。
-
可移植性好。在應用系統中添加數據訪問對象，可以使得前者能夠很方便地移植到另外一種數據庫實現上。業務對象與數據實現是隔離的，所以在移植過程中，僅僅對數據訪問對象進行一些變化即可。
-
減少業務對象的代碼復雜度。由于數據訪問對象可以管理所有的數據訪問復雜細節，這也就簡化了業務模塊和其他數據客戶的代碼。同時也提高了應用系統的整體可讀性和開發率。
-
集中處理所有數據訪問。由于所有的數據訪問操作都移交給數據訪問對象，這樣應用系統其他部分就與數據訪問實現隔離開來，而全部相關操作都與數據訪問對象集中處理，這樣也使得相關操作更加容易被維護和管理。
總之，在開發人員選擇不同模式的時候，應該注意，一定的模式對應于一定的應用層次。比如說，與視圖和顯示相關的模式就是在Web層應用的。而一些與業務邏輯控制相關的模式則是與EJB層次相關的。另外一些關于讀取數據和分派操作的模式則適用于不同的層次之間
7、值對象或傳輸對象
值對象(value object)模式通過減少分布式通信的消息而促進數據的交換，通常這里所指的通信是在Web層和EJB層之間。在一個遠程調用中，一個單一值對象可以被用來取出一系列相關數據并提供給客戶。
這種設計模式的出現是基于客戶需要與ejb大量地交換數據的情況。具體來說，在J2EE平臺中，應用系統通常將服務器端的程序組件實現為會話bean和實體bean，而這些組件的部分方法則需要將數據返回給客戶；這種情況下，通常一個用戶會重復調用相關方法多次，直到它得到相關信息，應該注意的是，多數情況這些方法調用的目的都是為了取得單一的信息，例如用戶名或者用戶地址等。
顯而易見，在J2EE平臺上，這種調用基本上都是來自遠程的。也就是說，用戶多次調用相應的方法會給Web帶來極大的負擔，即使用戶和EJB容器加載相同的JVM、OS和計算機上運行EJB程序，由于方法調用被缺省地認為是遠程任務，所以這種問題依然存在。
由于以上所提到的問題，在遠程方法的調用次數增加的時候，相關的應用程序性能將會有很大的下降，因此利用多次方法調用而取得單一的信息是非常低效的；在這種情況，J2EE的研究人員建議使用傳輸對象來包含所有的程序數據，即每次方法調用可以發送和接收這個傳輸對象；當用戶向EJB發出對于程序數據的請求時，EJB會創建這個傳輸對象，將它的各個域賦以相關的數值，并將整個對象傳送給用戶。
當EJB使用傳輸對象的時候，用戶可以通過僅僅一次方法調用來取得整個對象，而不是使用多次方法調用以得到對象中每個域的數值；由于傳輸對象是通過值傳遞而交送給用戶的，所以所有對于該傳輸對象的調用或取值都是本地調用，而不是遠程方法調用。不過需要注意的是，這個傳輸對象必須具有對應于每個屬性的訪問方法，或者將所有屬性都設為公共的。
類圖13表示了傳輸對象模式的體系結構。
.files/image026.jpg)
圖13 傳輸對象類圖
在圖13中，傳輸對象首先在EJB中創建，然后返回給遠程客戶；當然，傳輸對象也可以根據需要融合其他的設計模式。
圖14顯示了傳輸對象模式中的參與模塊和它們之間的交互。
.files/image028.jpg)
圖14 傳輸對象序列圖
下面我們說明一下傳輸對象模式的各個參與模塊：
(1)客戶(Client)。客戶代表了EJB所提供服務的使用者，通常是運行于用戶終端的應用程序。
(2)業務對象。業務對象表示在一個模式中由會話bean、實體bean或數據訪問對象(Data Access Object)實現的角色。業務對象通常負責創建傳輸對象，并根據請求將其傳送到相關的用戶；業務對象也可以從用戶中取得一個傳輸對象格式的數據，并應用這些數據來執行一些更新。
(3)傳輸對象。傳輸對象是一個可序列化的Java對象。在這個對象的類中，通常會有一個包含所有域的構造函數，用來創建這個傳輸對象。
這個傳輸對象中的成員變量基本都被定義為公共，從而無需為它們提供相關的訪問方法。當然如果存在一定安全的需要，相關的成員變量也可以設為保護或私有，并且給定各自的訪問方法。由此可見，傳輸對象的設計是隨著應用系統的需要不同而改變的，是否將對象中的成員變量設為公共，或提供一定的訪問方法，將是一個很重要的設計問題。
通常在實現這個模式時，最多采取的是可更新的傳輸對象策略和多傳輸對象策略。 在可更新的傳輸對象策略中，傳輸對象不僅可以從服務于用戶的業務對象中取得相關信息和數據，還可以從業務對象中得到用戶對于數據所需要進行的改變。
圖15以類圖表的形式表明了業務對象和傳輸對象之間的關系。
.files/image030.jpg)
圖15 可更新傳輸對象類圖
業務對象創建了傳輸對象。而用戶通過訪問業務對象，既得到了所需的信息，也對相關數據做出了一定的修改；為了能夠使得用戶可以修改業務對象各個域的取值，這個對象必須提供一定的變值方法，而出于對Web負擔的考慮，業務對象所提供的方法最好以傳輸對象為參數。相應地，這些方法可以去調用傳輸對象所提供的方法，來設置傳輸對象的各個成員變量的取值；同時在傳輸對象的方法中，我們也可以植入數據驗證和完整性檢查的邏輯，這樣在用戶從業務對象的方法得到傳輸對象時，可以直接調用傳輸對象的成員方法進行本地數據訪問，當然這種本地數據訪問不會影響到業務對象。
當用戶調用業務對象的變值方法時，該方法會將用戶端的傳輸對象序列化，再將它發送給業務對象；業務對象接收到更新的傳輸對象，便將這些更新寫回到自己的對象拷貝中去； 這里需要說明的是，上面提到的寫回只是涉及到被更新的變量，而不是全部變量的寫回，因此我們需要在傳輸對象中另設置一個變量，來指定哪些成員變量被用戶更新過，這也就使得這種模式的設計相對復雜，開發人員需要考慮同步化和版本控制的問題。
圖16顯示了這個更新過程的序列圖。
.files/image032.jpg)
圖16 可更新傳輸對象序列圖
多傳輸對象的方法是指一個單一的業務對象可以根據用戶請求制造多個不同的傳輸對象。也就是說，業務對象和它所創建的傳輸對象保持一對多的關系。類圖17表示了這種實現方法的各個參與模塊以及它們之間的調用關系。
.files/image034.jpg)
圖17 多傳輸對象類圖
當一個用戶需要A類型的傳輸對象時，他會激活相關EJB的getDataA()方法來取得傳輸對象A；當他需要B類型的傳輸對象時，他會激活getDataB()方法來獲取傳輸對象B；依此類推。序列圖18表示了這一過程。
.files/image036.jpg)
圖18 多傳輸對象序列圖
使用這種設計模式，應用系統的實體bean及其遠程接口會變得十分簡單。實體bean中無需再為每一個成員變量都實現一個set()和get()方法，并在遠程接口中實現相應的定義。用戶無需再進行多次的方法調用來取得信息和數據，所需要的只是一次方法調用以獲得整個傳輸對象。當然這里需要考慮Web負擔和大量數據一次傳輸的權衡。開發人員可以根據不同的需要來選擇不同的實現方法。
如上所述，用戶和實體bean之間可以通過在一次方法調用中使用傳輸對象而交換所有的數據，也就是說傳輸對象作為數據載體工作，并減少了遠程的方法調用，從而大大減輕了Web負擔。通過使用傳輸對象的方法，我們也將有可能減少實體bean和其傳輸對象間的代碼重復。不過在使用可更新的傳輸對象方法時，用戶可以修改其本地的傳輸對象，之后再將其傳送回業務對象中，后者將所需的更新整合到自己一端；但是這樣一來，就會存在一個版本控制的問題，不同的客戶可能在同時修改相同類型的傳輸對象，而如果相關的業務對象沒有發現這一點的話，可能就會造成一些用戶的數據沒有得到及時更新，而另外一些用戶的數據又被覆蓋的情況；在系統設計中必須考慮這個問題。
8、截取過濾器
截取過濾器(intercepting filter)主要用于對于用戶請求的之前處理和之后處理，也就是說它對于客戶的請求使用了額外的操作。比如說，servlet可以處理一個網站的所有客戶請求并提供一個核心的認證機制。
這種模式主要工作于表示層，負責處理不同類型的請求，同時也需要進行多種不同的處理。在這些請求中，有一些請求會直接傳送給后端模塊處理，而另外一些請求則先會在過濾器里解釋或補充內容，之后才能傳送給后端模塊。這種模式的提出主要是由于一個客戶的Web訪問和系統響應都需要一定的預處理和后處理，例如用戶身份、用戶環境信息、用戶請求的合法性等。通常這些處理的結果都會決定用戶的請求是否能夠進行，或是系統的響應應該用什么格式來表示。
對于這種預處理和后處理問題，傳統上，開發人員會設計一系列額外的檢測程序模塊，也就是一整套if/else語句，并且指定如果其中任何一個檢測失敗，所有的處理工作都會退出。顯然，這種方法是存在很大弊端的，即代碼的可讀性、可維護性都會被大大降低，同時將檢測工作融于一般的程序模塊，使得整個程序的模塊性難以保證。
解決這種問題的關鍵在于，設計一種簡單的技術，以能夠添加或移除額外處理的模塊，而這些模塊通常都能夠完成一定的檢測和過濾功能。根據以上的討論，J2EE研究人員提出了設計模式----截取過濾器作為解決方案，這種模式可以在不影響核心處理模塊的情況下，實現可插入的過濾器來執行一般的處理功能。
從理論上來說，這種過濾器可以截取客戶請求和系統響應，并進行相應的預處理和后處理；同時開發人員也可以隨時根據需要移除這些過濾器，并不用擔心會改變任何其他模塊。
我們這里所說的預處理和后處理功能，通常是指一些基本的系統服務，如安全、登錄，系統調試等。執行這些功能的過濾器通常是需要與核心模塊分開的，并且由于系統職能或規則的變化，這些模塊隨時可能被添加或刪除。
下面提供一些關于截取過濾器的圖示，以幫助大家更好地理解這種設計模式，并合理地加以運用。圖19表示了截取過濾器模式的整體結構，圖19顯示了截取過濾器中的參與模塊和相互之間的聯系。
.files/image038.jpg)
圖19 截取過濾器模式
.files/image040.jpg)
圖20 截取過濾器序列圖
下面我們分別來說明圖20中的各個模塊：
(1)過濾管理器(Filter Manager)。過濾管理器負責過濾器的主要處理工作，即創建過濾器鏈對象以及相應的過濾器組建，并初始化整個處理過程。
(2)過濾器鏈(Filter Chain)。過濾器鏈是一組互不依賴的過濾器有序集合。
(3)過濾器1，過濾器2，過濾器3(FilterOne，FilterTwo，FilterThree)。這些都是提供不同服務的過濾器，而過濾器鏈則負責它們的協調工作。
通過采用這種設計模式，應用系統可以取得更方便的中心控制，這是由于過濾器可以提供處理多種請求的中心模塊，并能根據后端的處理模塊而解釋和潤色用戶的請求，使得該請求能更好地與處理模塊所提供的功能匹配。另外，過濾器通常可以將不同種類的服務聚集在一起，并提供相當靈活的服務組合，應用系統可以通過使用截取過濾器提高其重用性，過濾器可以隨時根據需要從其他程序模塊中插入或移除，并且由于它們通常具有標準的接口，開發人員可以使用一組類似的過濾器，并在不同的情況下進行全組的重用。
采用這種設計模式也會帶來一定的問題，即在過濾器之間共享信息將變得非常困難，這是由于根據其定義和需求，每個過濾器的設計和開發都大相徑庭。因而如果在不同的過濾器之間需要共享信息的話，其代價將是非常昂貴的。
作者：務實，多年從事J2EE網站及應用系統項目的開發和應用。
參考資料：
《J2EE設計開發編程指南》 Rod Johnson 電子工業出版社
《J2EE參考大全》 Jim Keogh 電子工業出版社
《實用J2EE設計模式編程指南》 Craig A.Berry 電子工業出版社