J2EE體系架構設計介紹(2) 會話面、數據訪問對象
圖6中的類圖簡要描述了會話面的設計模式，圖7給出了會話面的序列表示，即參與組件及其交互關系。
圖6 會話面類圖
圖7會話面序列圖
這里我們對于圖7的各個組件加以簡要的介紹：
(1)客戶(Client)。這表示會話面的客戶，即需要訪問相關企業服務的客戶端應用程序，當然也可以是在同一層面或不同層面的另外一個會話bean。
(2)會話面(Session Facade)。會話面通常是用會話bean來實現的，它管理著多個企業對象的作用關系并提供一個高層次的抽象界面給用戶。
(3)業務對象(Business Object)。業務對象是一個可以使用多個不同設計方案的對象，例如會話bean、實體bean和數據訪問對象。在圖6中業務對象負責提供數據和服務，而會話面則需要與多個業務對象實例交互而獲得相應的服務。
會話面實際上就是業務層的一個控制對象，它負責控制用戶與企業數據和企業服務對象之間的交互；在一個復雜的應用系統中，甚至可能會有多個會話面作為用戶和對象模塊之間的中介。
下面介紹兩種實現會話面的常見方法。
(1)無狀態的會話面
在實現會話面的時候，首先應該決定是用狀態化還是無狀態的會話bean來實現，這主要取決于會話面所建模的業務流程；如果一個業務流程只需要一次方法調用就可以實現其服務，那么就可以使用無狀態的會話bean來實現它。
(2)狀態化的會話面
當一個業務流程需要多次方法調用來實現其服務時，開發人員***使用狀態化的會話bean來實現這***程，因為每次方法調用的狀態信息都必須在會話bean中保存。
通過在應用系統中采用會話面的設計模式，將在系統中得到以下的收益：
①為用戶提供一個簡單的接口，并隱藏所有與系統組件復雜的交互過程；
②減少暴露給用戶的企業對象，從而降低它們之間的依賴關系；
③向用戶隱藏系統組件間的交互過程和依賴關系，從而使得系統更加容易管理，并提供相當的靈活性；提供一套統一的用戶訪問機制，便于管理用戶對于系統服務的請求與訪問。
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是這種設計模式的序列圖。
圖8 數據訪問對象類圖
圖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是這種方法的類圖。
圖10 使用DAO代理類圖
當底層的數據存儲可能會變化的時候，開發人員可以采用抽象代理的方法來實現數據訪問對象；抽象代理的方法會創建一些虛擬的數據訪問對象代理和各種類型的實際數據訪問對象代理，每種對象對應一種持久性存儲介質的實現，一旦組件得到這些代理，就可以利用來創建需要使用的數據訪問對象。
圖11給出了這種情況的類圖。該類圖表示了一個基礎的數據訪問對象代理，它是一個抽象類，被其他一些實際的數據訪問對象代理繼承以支持特定的數據訪問函數；用戶可以得到一個實際的數據訪問對象，并利用它來創建需要的數據訪問對象而訪問相關的數據，每一個實際的數據訪問對象都負責建立對于數據源的連接，并得到和管理所支持的業務數據。
圖11 抽象代理使用DAO
下圖12是這種情況下的序列圖。
圖12抽象代理使用DAO序列圖
這種設計模式的優勢：
透明性好。業務對象可以在不知道數據源實現細節的情況下訪問數據。由于一切數據訪問細節被數據訪問對象所隱藏，所以這種訪問過程是透明的。
可移植性好。在應用系統中添加數據訪問對象，可以使得前者能夠很方便地移植到另外一種數據庫實現上。業務對象與數據實現是隔離的，所以在移植過程中，僅僅對數據訪問對象進行一些變化即可。
減少業務對象的代碼復雜度。由于數據訪問對象可以管理所有的數據訪問復雜細節，這也就簡化了業務模塊和其他數據客戶的代碼。同時也提高了應用系統的整體可讀性和開發率。
集中處理所有數據訪問。由于所有的數據訪問操作都移交給數據訪問對象，這樣應用系統其他部分就與數據訪問實現隔離開來，而全部相關操作都與數據訪問對象集中處理，這樣也使得相關操作更加容易被維護和管理。
這種設計模式的缺陷：
對于容器管理的持久性不能利用。如果EJB容器采取容器管理的方式，那么所有對于持久性數據存儲的管理都由容器負責。這樣的話應用系統就無需實現數據訪問對象了，因為應用服務將透明地提供這一功能。
添加了額外的層面。數據訪問對象在數據用戶和數據源之間添加了一個層面，也就增加了一些額外的設計和實現的負擔。當然，我們認為它是物有所值的。
總之，在開發人員選擇不同模式的時候，應該注意，一定的模式對應于一定的應用層次。比如說，與視圖和顯示相關的模式就是在Web層應用的。而一些與業務邏輯控制相關的模式則是與EJB層次相關的。另外一些關于讀取數據和分派操作的模式則適用于不同的層次之間。
【編輯推薦】
