兩種設計模式在EJB開發中的應用

2019-11-18 13:33:14

字體：大中小

來源：轉載

供稿：網友

　　摘要:本文介紹了J2EE的分層結構,深入研究了如何使用session Facade模式和ValueObject 模式設計EJB，并對其開發過程做了較具體的說明。

　　要害字:EJB ;值對象模式;會話外觀模式

　　一、概述

　　與傳統的二層體系結構相比，J2EE有兩個特點：

　　1、定義了一套標準化組件,通過為這些組件提供完整的服務。

　　2、使用多層分布式的應用程序模型。應用程序的邏輯根據其實現的不同功能被封裝到不同的組件中。如圖1所示。

兩種設計模式在EJB開發中的應用（圖一）

　　這種多層結構使企業級應用具有很強的伸縮性,答應各層專注于某種特定的角色:

　　1、Client Tier用于顯示。

　　2、Web Tier用于生成動態顯示。

　　3、Business Tier用于實現業務邏輯。

　　4、EIS Tier用于數據庫服務。

　　其中，用于實現業務邏輯的EJB組件架構是J2EE的基礎和最重要的部分。

　　正是熟悉到J2EE平臺作為一種可擴展的、全功能的平臺，可以將要害的企業應用擴展到任何Web瀏覽器上并可適合多種不同的Internet數據流、可連接到幾乎任何一種傳統數據庫和解決方案，J2EE已經成為開發電子商務應用的事實標準。

　　為了使開發者開發出規范的、可重用的應用程序，J2EE為我們提供了大量的模式。模式盡管有時不易理解，但使用卻非常簡單，它提供了強大的可重用機制，避免了開發者和設計者的重復投資。

　　可是，面對如此多的模式，初學者往往不知如何下手，為此，作者結合以往的開發經驗，具體介紹如何使用模式完成EJB的設計。

QQ病毒騰訊QQ空間代碼專題 PPT教程專題 ADSL應用面面俱到 fireworks教程專題計算機和網絡技術基礎知識校園網專題網吧技術專題

二、設計與實現

　　1．值對象模式

　　J2EE應用程序把服務器端業務組件實現為會話Bean和實體Bean。對于實體Bean的創建，開發人員通常采用CMP(容器治理持久性)模式，其好處在于容器提供公共的服務,例如目錄服務、事務治理、安全性、持久性、資源緩沖池以及容錯性等,使開發人員不必維護將會集成到業務邏輯中的系統級代碼,只需專注于商業邏輯。

　　一般來說，有了實體bean，就可以通過調用業務組件的一些方法向客戶端返回數據。初學者往往會認為既然客戶端可以與服務器通信，那么任務就算完成了。可是，問題恰恰出在這里。業務組件的get方法只能返回一個屬性值，這就導致需要獲得所有屬性值的客戶端需要多次調用業務對象的get方法，如圖2-1所示。每次調用都是一次網絡調用,都會造成系統性能的退化,當調用次數增多時，系統性能就會嚴重下降。

　　這就要求有一種方法使客戶端可以一次調用得到所需的大量數據，這種方法就是Value Object(值對象)模式。值對象是任意的可串行化的java對象，也被稱為值的對象，它在一次網絡傳輸中包含和封裝了大量的數據并被保存在內存中。這樣，當客戶端需要再次使用數據的時候,不用再次到數據庫中查詢,而是直接在內存中讀取值對象,節省了大量的時間和系統開銷，如圖2-2。

　　值對象模式有兩種策略――可更新的值對象策略和多值對象策略。

　　可更新的值對象策略中，業務對象負責創建值對象，并且在客戶端請求時把該值對象返回給客戶端；同時，業務對象也可以從客戶端接收數據，形成值對象，并使用該對象來完成更新。

　　例如，在銀行系統的例子中,Account 中提供一個以AccountValue為參數的setAccountValueObject方法，這樣客戶端可以通過這個方法來設置值對象的值，而不采用實體bean--Account中設置每個屬性的方法（setBalance()），因為后一種方法會導致大量的網絡負載。由于值對象的易變性，所以值對象類必須給每個可以被客戶端更新的屬性提供設置方法。例如，AccountValue中的setBalance（）方法。這樣，一旦某客戶端擁有來自業務對象的值對象，客戶端就可以在本地調用必要的設置方法來更改屬性值，然后調用業務對象的setAccountValueObject()方法更新業務對象。

　　多值對象策略

　　一些應用程序業務對象往往比較復雜，在這種情況下，根據客戶端請求不同，有可能單個業務對象會產生多個不同的值對象。在這種情況下，可以考慮采用多值對象策略。這種策略的實現比較簡單，就是在entity bean中增加不同的Get×××ValueObject（）方法和set×××ValueObject()方法。

　　2．Session Facade 模式

　　有了實體Bean，客戶端就可以直接調用它以獲得數據。也就是說實體Bean封裝了業務數據，并把他們的接口暴露給客戶，因而也就把分布式服務的復雜性暴露給客戶。在對J2EE 應用程序環境下，一般會產生如下問題：

　　1、緊密耦合，這回導致客戶端和業務對象的直接依靠關系

　　2、客戶端和服務器之間的網絡方法調用太多，輕易導致網絡性能問題

　　3、缺乏統一的客戶訪問策略，輕易誤用業務對象

　　4、假如實體bean的API改動，那么用戶端的一些代碼也要修改，擴展性很差

兩種設計模式在EJB開發中的應用（圖二）

　　解決這些問題的方法就是把客戶端和實體bean分割開。本文采用Session Facade模式，如圖3-2所示。該模式通過一個Session Bean，為一系列的實體bean提供統一的接口來實現流程。事實上，客戶端只是使用這個接口來觸發流程。這樣，所有關于實體bean實現流程所需要的改變，都和客戶端無關。當實體bean改變時,我們不用改變客戶端的代碼,只要對Session Bean做出相應的改變即可,大大提高了系統的可維護性。

　　通過實體bean來表示業務對象是session fa?ade的最常見用法。但多個實體bean參與某用例時，不必向客戶暴露所有實體bean。相反的，用session bean 包裝這些實體bean ,并且提供粗粒度方法來執行所需的業務功能，從而隱藏了實體bean交互的復雜性。

　　但是千萬不要以為Fa?ade模式就是簡單的用Session Bean把Entity Bean的所有方法統統封裝起來,而不提供任何額外的抽象。其實這是對Fa?ade模式的濫用。這樣做并不是降低整個系統的復雜性,而是把復雜性轉移到另一個對象上。

　　正確應用Facade模式應遵循三條基本原則:

　　1、他們自己不作實際工作,而是委派其他對象作實際工作。

　　2、他們提供簡單的接口。

　　3、他們是底層系統的客戶端接口。他們應該把特定于子系統的信息封裝起來,并且不應該在不必要的情況下公開它。

上一篇：混合Eclipse、WTP、Struts和Hibernate

下一篇：快速上手Eclipse Eclipse快捷鍵指南