一． 設計模式重要性
采用ＥＪＢ技術的Ｊ２ＥＥ項目中，ＥＪＢ架構的設計好壞將直接影響系統(tǒng)的性能、可擴展性、可維護性、組件可重用性及開發(fā)效率。項目越復雜，項目隊伍越龐大則越能體現(xiàn)良好設計的重要性。
二． 常見EJB設計模式
Session Facade Pattern
通常項目中，客戶端往往需要頻繁的對服務器端數(shù)據(jù)進行操作。當采用實體ＥＪＢ作為數(shù)據(jù)的抽象層時，如果直接讓客戶端程序與實體ＥＪＢ交互，會產(chǎn)生實現(xiàn)一個業(yè)務需求便需要大量的ＥＪＢ屬性操作（如下圖１）。這直接導致如下問題：網(wǎng)絡負載大（遠程客戶端時）、并發(fā)性能低、客戶端與服務器端關聯(lián)度大、可重用性和可維護性差、性能
因此有必要在客戶端與實體ＥＪＢ層間加入Session ＥＪＢ層，在Sessino EJB中實現(xiàn)商業(yè)邏輯并封裝對實體ＥＪＢ的操作。（如下圖２）
圖１：客戶端直接與實體ＥＪＢ交互
圖２：通過SessionEJB層實現(xiàn)
Session Fa?ade模式的好處是：降低了網(wǎng)絡負載，SessionEjb可以調(diào)用實體ＥＪＢ的本地接口；將商業(yè)邏輯與商業(yè)數(shù)據(jù)隔離；維護與開發(fā)方便；顯著提高性能。
Session Fa?ade模式因其簡單使用，是目前使用很廣的模式。但具體應用過程中應注意：避免將所有的操作封裝到一個很大的SessionEJB內(nèi)；服務器端數(shù)據(jù)結構應由實體EJB實現(xiàn),除非特例否則避免直接的數(shù)據(jù)庫操作；SessionEjb內(nèi)某些系統(tǒng)通用操作的代碼容易重復（比如權限檢查等，解決辦法是將系統(tǒng)通用服務封裝在Java Class內(nèi)）。
Message Facade Pattern
很多時候，一次Request需要操作多個ＥＪＢ又不需要得到即時返回。對這種異步調(diào)用，通常應用Message Fa?ade Pattern.
這種時候，如采用Session Fa?ade Pattern存在如下問題：
1. 客戶端等待返回的時間過長。一個SessionEjb的實例在完成客戶請求過程中中涉及到的每一次對其他實體Ejb的調(diào)用過程中都會被鎖定直到得到實體EJB返回信息后才能進行下一步操作。這樣造成客戶不必要的等待，并很容易因時間導致整個事務失敗。
2. 系統(tǒng)可靠性和容錯性低。如果需要調(diào)用不同系統(tǒng)或服務器上或多個異構數(shù)據(jù)源的多個ＥＪＢ時，任何一個環(huán)節(jié)出錯，均導致客戶請求失敗。
以Message-Driven Bean為基礎的Message Facade Pattern則可以解決上述異步請求需求。具體架構見下圖３
圖３：使用Message Facade Pattern
Message Facade Pattern的不足之處在于：
１． Message-Driven Bean沒有返回值。這樣通知客戶執(zhí)行結果只能依賴于Ｅｍａｉｌ或人工等其他手段。
２． Message-Driven Bean執(zhí)行過程中無法將捕獲的異常直接返回給客戶端，即無法使客戶端直接直到錯誤信息。
３． Message-Driven Bean通過接收Message響應客戶請求，對Message內(nèi)容的合法性（比如對象的類型等）依賴與客戶端.容易產(chǎn)生運行時錯誤。
Message Facade Pattern經(jīng)常與Session Facade Pattern在同一個項目里共同使用。
EJB Command Pattern
Session Facade Pattern中將商業(yè)邏輯實現(xiàn)封裝在Session EJB中，這種做法帶來諸多益處之外也帶來如下問題：
１． 由于業(yè)務經(jīng)常的變化，導致經(jīng)常需要更新Session EJB代碼。
２． 客戶端代碼不得不包含大量EJB相關的ＡＰＩ，不利于后期項目維護。
３． 項目開發(fā)測試需要經(jīng)常的EJB重部署過程。
引起上述問題的重要根結就是Session EJB本身重量級組件，其開發(fā)測試部署工作量較大，開發(fā)周期較長。以上不足可以通過EJB Command Pattern克服。
EJB Command Pattern中將商業(yè)邏輯實現(xiàn)封裝在普通的Java Class（稱之為Command Bean）中。該模式的具體實現(xiàn)有很多種，通常的框架都包括三部分：
１． Command Bean.由應用開發(fā)者寫的具體實現(xiàn)某商業(yè)操作的Java Class.主要包含getXXX(),setXXX(),execute()方法。
２． Client-Side Routing Logic.由多個Class組成，用于將請求轉發(fā)至Command Sever，這個過程對客戶是透明的。這部分代碼可以跨項目使用。路由規(guī)則中可以考慮用ＸＭＬ技術。
３． Remote Command Server.實際執(zhí)行商業(yè)操作請求。通常可以用Session EJB層實現(xiàn)。
整個框架見下圖４：
圖４：Command的基本框架
EJB Command Pattern具有如下好處：
１． 適應與需要快速開發(fā)環(huán)境。因Command Bean是輕量級的Java Class，其編譯和調(diào)試比較方便。
２． 將表現(xiàn)層與商業(yè)實現(xiàn)層隔離，同時將客戶端代碼與EJB層隔離。
３． 將客戶端代碼開發(fā)與服務器端代碼開發(fā)相對清晰。早期可以創(chuàng)建空的Command Bean方便客戶端代碼調(diào)試。
EJB Command Pattern的弱處在于：
１． Command Bean中對事務的控制不如Session EJB中。
２． Command Bean是無狀態(tài)的。
３． 無法將異常直接返回給客戶。
４． 在大項目中，由于商業(yè)邏輯復雜，常導致大數(shù)量的Command Bean存在.
５． 作為Command Server的Session EJB打包時必須包含Command Bean以致存在維護上的不便。
EJB Command Pattern的一個實際實現(xiàn)可以參考IBM's Command Framework.
Data Transfer Object Factory
基于EJB的J2EE項目，經(jīng)常需要在客戶端與服務器端傳輸大量數(shù)據(jù)。數(shù)據(jù)的組織形式常用的是DTO(Data Transfer Object，服務器端數(shù)據(jù)對象的抽象)。但因為客戶端表現(xiàn)層經(jīng)常是變化的，所需要服務器端數(shù)據(jù)也變動頻繁，換句話說，DTO的數(shù)量和屬性經(jīng)常要更改。因此如何以及在何處生成和維護DTO便是需要考慮的問題。
一種解決方案是直接在Entity EJB中直接處理，即在Entity EJB的Bean類中加入getXXXDTO()、setXXXDTO()等。但這樣做導致EJB與DTO層緊緊綁定。一旦DTO更改，與該DTO相關的EJB即需要重編譯打包。EJB層與客戶端層相關聯(lián)不僅使維護困難而且導致EJB的重用性大大降低。
更好的解決方案是利用Data Transfer Object Factory封裝對DTO的操作邏輯（如下圖６）。
圖６：DTO Factory示例
DTO Factory具體實現(xiàn)方式通常有兩種：
１． 普通Java Class實現(xiàn)，用于Session Facade Pattern使用DTO環(huán)境下。
２． Stateless Session EJB實現(xiàn)，用于非EJB客戶端使用DTO環(huán)境下（見圖７）。
圖７：SessionEJB實現(xiàn)DTOFactory
DTO Factory帶來如下好處：
１． 使Entity EJB的重用成為可能。由于不含DTO處理邏輯，Entity EJB功能單一化，只作為數(shù)據(jù)源。不通客戶端通過各自的DTO Factory可以從同一個Entity EJB得到各自所需的個性化數(shù)據(jù)（自定義DTO）。
２． 提高可維護性和性能。
３． 可以根據(jù)在DTO Factory層生成很復雜的DTO結構，諸如繼承、關聯(lián)關系等，而對客戶端提供一個透明、細化的數(shù)據(jù)接口。
使用DTO Factory時需要注意的是：不需為每個Entity EJB定義一個Factory。可以為一系列相關的Entity EJB創(chuàng)建一個Factory，或者只創(chuàng)建一個Factory。
Generic Attribute Access
使用Entity EJB作為商業(yè)數(shù)據(jù)層時，我們首先需要從數(shù)據(jù)庫加載數(shù)據(jù)，創(chuàng)建對應的Entity EJB實例，之后對內(nèi)存中Entity EJB實例的屬性進行相應操作。對屬性的操作比較直接的做法是：直接調(diào)用Entity EJB的getXXX()/setXXX()，通常利用EJB2.0的本地接口；通過DTO Factory生成DTO。但這兩種做法都存在如下問題：
１． 當Entity EJB的屬性特別多時候，以上做法會帶來復雜羅嗦的代碼，使EJB變的龐大無比。
２． 使Entity EJB的客戶端（比如Session EJB）和Entity EJB的接口緊密關聯(lián)。Entity EJB屬性的增刪都需要更改客戶端代碼，給項目開發(fā)和維護帶來不便。
事實上可以利用更通用的方式訪問Entity EJB的屬性，即定義Generic Attribute Access Interface。見下圖８：
圖８：Generic Attribute Access Interface示例
Generic Attribute Access Interface由Entity EJB的本地或遠程接口實現(xiàn)，并利用Hash Maps傳輸數(shù)據(jù)。實現(xiàn)方式常見如下：
１． BMP類型實體EJB可以在Bean類中定義包含所有屬性的私有成員變量HashMap。
２． CMP類型實體EJB可以在Bean類中可以適用Java Reflection API實現(xiàn)。
３． 建立一個父類，在不同的情況下定義子類重載父類方法。
使用Generic Attribute Access Interface需要在客戶端與服務器端對屬性以及對應的關鍵字建立統(tǒng)一的命名習慣。常見的做法如下：
１． 建立并保持良好的文檔記錄和命名約定。
２． 在實體EJB的實現(xiàn)類中定義靜態(tài)成員映射屬性。
３． 創(chuàng)建共享靜態(tài)類，通過成員變量映射實體EJB屬性。
４． 通過JNDI在服務器端保存屬性映射關系。
Generic Attribute Access Interface的運用帶來一下益處：
１． 接口實現(xiàn)后對不通實體EJB都適用。
２． 對屬性較多實體EJB能精簡代碼，并更具維護性。
３． 使運行中動態(tài)增刪實體EJB屬性成為可能。
Generic Attribute Access Interface的缺點在于：
１． 訪問EJB屬性時增加了額外的操作。需要通過關鍵字映射屬性，最后還需進行類型轉換。
２． 需要建立客戶端與服務器端的命名約定。
３． 因為通過HashMap操作時候需要進行類型轉換，容易產(chǎn)生運行時類型不匹配異常。
Business Interface
EJB規(guī)范要求Bean實現(xiàn)類必須實現(xiàn)所有在遠程（或本地）接口中定義的所有方法，同時不允許Bean實現(xiàn)類直接繼承遠程（或本地）接口。這就導致編譯時候很容易產(chǎn)生兩者不一致的問題，即遠程（或本地）接口中定義的某方法為在Bean實現(xiàn)類中被實現(xiàn)等錯誤。為避免上訴錯誤，可以利用應用服務器廠商所提供的工具。但也可以應用EJB的設計架構來實現(xiàn)：定義商業(yè)接口。
Business Interface即創(chuàng)建自定義商業(yè)接口，在接口中定義所有EJB提供的商業(yè)方法，并讓Bean實現(xiàn)類和遠程（或本地）接口都實現(xiàn)該商業(yè)接口。其繼承關系見下圖９：
圖９：商業(yè)接口的使用
Business Interface是個普通的Java Class。依賴于使用本地接口與遠程接口的不通，Business Interface的定義略有不同：應用與遠程接口時，在接口中的方法需要拋出java.rmi.RemoteException；而應用與本地接口時候則不需要作任何特別處理。
應用Business Interface時候必須注意一點：EJB規(guī)范不允許直接EJB的實例將對自己的引用（this對象）返回給客戶端，否則編譯時候即報錯。但使用Business Interface后，編譯時候無法檢查出有無將this對象返回給客戶端。這一點需要程序員自己保證。
三． 內(nèi)部數(shù)據(jù)轉換策略
Data Transfer Object
基于EJB的J2EE多層架構應用中，經(jīng)常涉及的一個問題就是如何在各層之間傳遞批量數(shù)據(jù)，比如客戶端對服務器端數(shù)據(jù)的批量讀寫操作等。比如需要得到實體EJB的屬性，直接的方法是多次調(diào)用不通的屬性，如下圖１０：
圖１０：低效的數(shù)據(jù)傳遞方式
但這種方法容易導致許多問題，比如性能以及代碼的復雜度等，更有效的辦法是在一個調(diào)用中得到所有需要的屬性。所以可以引入Data Transfer Object來封裝所需要的屬性，并在客戶與服務器端通過傳遞該對象一次實現(xiàn)對數(shù)據(jù)的操作。如下圖１１：
圖１１：通過DTO傳遞數(shù)據(jù)
DTO為普通的Java Class，通常是服務器端數(shù)據(jù)的快照。由于網(wǎng)絡傳輸?shù)男枰珼TO應該實現(xiàn)java.io.Serializable接口。
DTO的設計有兩種模型：Domain DTO以及Custom DTO。
Domain DTO僅僅實現(xiàn)對服務器數(shù)據(jù)的拷貝，通常與實體EJB為一對一的關系(也存在為多個相關聯(lián)的實體EJB對應一個Domain DTO)。Domain DTO通常除用于讀取更改實體EJB屬性外也可用于創(chuàng)建實體EJB時候。實體EJB與Domain DTO對應關系如下圖１２：
圖１２：Account EJB 與 Account DomainDTO
Domain DTO的應用除了DTO所具有的一般優(yōu)點外，還有別的益處：
１． 開發(fā)迅速。因為一旦實體EJB設計好后，很容易轉換得到Domain DTO。
２． 可以利用Domain DTO的setXXX()方法在客戶端進行屬性有效性效驗。
Domain DTO的缺點有：
１． 客戶端綁定了服務器端數(shù)據(jù)模型，不利于維護。
２． 不夠靈活，無法處理客戶端的多樣化數(shù)據(jù)要求。對一個數(shù)百個屬性的實體EJB請求一個屬性時候卻返回一個包含所有屬性值的Domain DTO明顯是笨重的實現(xiàn)。
３． 導致代碼的重復。
４． Domain DTO中如果嵌套包含了別的Domain DTO時，一旦需服務器端數(shù)據(jù)的更改而需要重定義Domain DTO模型時候異常困難。
Custom DTO則可以克服上述的一些缺點。Customer DTO僅僅封裝用戶感興趣的服務器數(shù)據(jù)集即可以根據(jù)客戶端需求創(chuàng)建Customer DTO。這樣作的優(yōu)點是靈活高效；缺點是大項目中可能導致大量的Customer DTO存在。
通常Domain DTO可以用于數(shù)據(jù)的更新與創(chuàng)建；Customer DTO可以用于客戶用于表現(xiàn)層的數(shù)據(jù)讀取。兩者可以相輔相成。而且使用DTO一般與DTO Factory同時使用。
Domain Transfer Hash Map
DTO的使用往往缺乏通用性。不通的用戶案例需要創(chuàng)建不同的DTO。當項目很復雜時，從維護性考慮需要更好的數(shù)據(jù)傳輸?shù)膶崿F(xiàn)方式。
Domain Transfer Hash Map即利用HashMap作為客戶所需數(shù)據(jù)集的封裝。好處是：
１． 良好的維護性。
２． 較大的通用性。不同的客戶端可以使用相同的數(shù)據(jù)傳遞方式。
缺點是：
１． 需要維護客戶端與服務器端在屬性及其對應關鍵字的映射關系。
２． 當需要使用基本類型的數(shù)據(jù)時候，因為Hash Map的限制必須將基本類型先轉換成對象。
３． 使用得到的數(shù)據(jù)時，需要進行類型強制轉換。
Data Transfer RowSet
當需要處理直接的JDBC調(diào)用得到的結果集時，顯然用DTO/Hash Map已經(jīng)不合適，因為需要對大量數(shù)據(jù)進行類型轉換等額外操作是很費資源和不必要的，而且最終用戶常需要以表格式樣顯示數(shù)據(jù)。
所以對二維表式數(shù)據(jù)，更好的處理方式是利用Data Transfer RowSet。Data Transfer RowSet通過將ResultSet直接轉換為RowSet傳遞給客戶端。
在Session EJB中使用RowSet的一段示例代碼如下圖１３：
圖１３：使用RowSet
使用RowSet的好處很多：
１． 接口通用于各樣的數(shù)據(jù)庫查詢操作。
２． 當需要表格式數(shù)據(jù)顯示時，因為直接從ResultSet得到，所以不需要額外的數(shù)據(jù)類型轉換。
缺點是：
１． 數(shù)據(jù)庫結構暴露給客戶端。
２． 不符合面向?qū)ο笤O計思想。
３． 依賴于SQL。
Data Transfer RowSet通常用于只讀式數(shù)據(jù)的顯示操作，經(jīng)常和JDBC for Reading Pattern連用。
四．事務和數(shù)據(jù)持久機制
JDBC for Reading Pattern
基于EJB的J2EE應用中，通過EJB對數(shù)據(jù)庫的操作可以有兩種方式：實體EJB或者Session EJB中直接利用JDBC訪問。
客戶很多時候取出數(shù)據(jù)庫中數(shù)據(jù)并以表格方式顯示。這種情形如果使用實體EJB會導致如下問題：
１． 引用服務器端頻繁的數(shù)據(jù)庫查詢和加載操作。因為加載N個實體EJB總需要進行一次find()操作 N次數(shù)據(jù)加載。
２． 如果使用Remote接口，引起頻繁的額外網(wǎng)絡操作。
３． 對關聯(lián)關系比較復雜的數(shù)據(jù)庫表結構，很難直接通過Entity EJB表現(xiàn)。
因此建議在只需對數(shù)據(jù)庫表數(shù)據(jù)進行只讀訪問時候，應該采用JDBC for Reading Pattern，即通過JDBC直接訪問數(shù)據(jù)庫。除了避免上述使用實體EJB的缺點還帶來一下好處：
１． 充分利用數(shù)據(jù)庫能力，比如數(shù)據(jù)庫的緩存機制。
２． 減少了對事務控制的資源。
３． 利用自定義SQL可以按需要比較靈活的讀取數(shù)據(jù)。
４． 只需要一次數(shù)據(jù)查詢，減少了數(shù)據(jù)庫操作。
缺點是：
１． 于J2EE應用的面向?qū)ο笤O計相違背。
２． 因為Session EJB代碼中包含了自定義SQL，維護性差。
３． Session EJB中不得不包含JDBC的API，并且需要了解數(shù)據(jù)庫結構。