模式與J2EE

2019-11-17 04:44:00

字體：大中小

來源：轉載

供稿：網友

信息工程是以當前數據系統為基礎，在一個企業或企業的主要部門，關于建設信息系統的規劃、分析、設計和構成的一整套相互關聯的正規化、自動化的技術應用?！狫ames Martin 正如上面信息工程的創始人James Martin為信息工程的概念所做定義類似，模式(Patterns)的創始人建筑師Christopher Alexander在<模式語言，1977、1979>一書中對模式的概念進行了如下描述(附注：書名后面的年份代表在各個不同時期的作品，下面形式同上)：每一個模式描述了一個在我們四周不斷重復發生的問題，以及該問題的解決方案的核心。這樣，你就能一次又一次的使用該解決方案而不必做重復勞動。每個模式是由三部分組成的一個規則，這個規則描述特定環境、問題和解決方案之間的關系。簡單的說，沒有一個模式是獨立的實體，每個模式都存在著相互支持，但支持的程度不同：大的模式可以內嵌小的模式，同等層次的模式并列存在，而小的模式被嵌入到大的模式之中?！狢hristopher Alexander 模式的概念在軟件行業被采用以后，得到的廣泛的發展，現在已經存在許多種類型的模式應用，其中比較有名的箸作有：GoF(Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides四人，簡稱：Gang of Four[GoF])的<設計模式，1995>，Martin Fowler的<分析模式，1997>，Frank Buschmann等人的<體系結構模式，1996、2000>、Jim O.Coplien、Niel Harrison等人的<編程模式，1995、1996、1998、1999>和Deepak Alur等人的等，其中最具影響的是GoF的<設計模式>一書，書中具體討論了三種類型，共23種模式。好的設計源于工作中經驗的積累，當設計使用標準的模板以模式的方式進行交流時，模式就成了交流和重用的強大機制，并且可以改善設計和開發軟件的方式。模式可以幫助我們在一個特定的環境里整理并記錄已知的可重現的問題及解決方案，并且通過模式來與他人交流這些知識，這些模式可以解決在不同環境中重復出現的問題。模式可以使設計重復使用，重復使用已知的解決方案可以縮短設計和開發應用的周期，有效的使用模式，可以使我們遠離重復投資的怪圈。模式的要害在于簡單性和可重現性。舉一個模式應用的簡單示例。例如，在你的便攜式電腦上運行一個進程中的對象，并且這些對象需要和運行在另一進程中的別的對象通信，也許這一進程并不在你的便攜式電腦上，而在別的地方。你又不想讓系統中的對象擔心如何找尋網上的其他對象或者執行遠程過程調用。這時，可以使用代理(PRoxy模式，詳見GoF的<設計模式>一書)模式來解決這個問題，你能做的事就是為這個遠程對象在你的本地過程中建立一個代理對象，該代理對象和遠程對象具有相同的接口。你的本地對象利用通常處理過程中的消息發送來和代理交談。這時代理對象負責把消息傳送給實在對象，而不管實在對象位于何處。由于下面要講的java 2平臺的企業版(J2EE)應用模式中很多用到了設計模式與重構(Refactoring)的概念，所以在此有必要再概要介紹一下重構的概念。重構已經被證實可以阻止軟件的腐朽和衰敗，關于重構方面的有名箸作當然首推是Martin Fowler所寫的<重構，1999>一書了，書中具體介紹了重構的七大類型，共70余種具體的重構手法，同時也指出測試機制在重構中的重要性。書中Martin Fowler對重構的概念進行了具體說明：構是對軟件內部結構的一種調整，目地是在不改變[軟件之可察行為]的前提下，提高其可理解性，降低其修改成本。重構是一種有紀律的、經過練習的、有條不紊的程序整理方法，可以將整理過程中不小心引入的錯誤的機率降到最低，本質上說，重構就是在代碼寫好之后改進它的設計。重構之前，首先檢查自己是否有一套可靠的測試機制，這些測試必須有我檢驗能力?！?Martin Fowler 建立于Java編程語言和Java技術基礎之上的J2EE平臺是最適用于企業級分布式環境的應用結構，它被設計為面向多層體系的結構。J2EE包含下面要害技術：Java服務器頁面(Java Service Page，jsp)、Servlet、Enterprise JavaBeans(EJB)組件、Java消息服務(Java Message Service，JMS)、JDBC和Java命名與目錄接口(Java Naming and Directory Interface，JNDI)。由于J2EE平臺是分層系統，所以我們將J2EE的層次模型化，這個模型使得我們將職責邏輯地分到不同的層中，共分了五個層次：客戶層、表示層、業務層、集成層和資源層。因為客戶層和資源層并不是J2EE平臺直接關注的問題，所以后面介紹的15個J2EE應用模式全部屬于上面五層中的中間三層，其中表示層模式包含與Servlet和JSP技術相關的模式、業務層模式包含與EJB技術有關的模式、集成層模式包含與JMS和JDBC有關的模式。具體模式可參看下面表格：表一：表示層模式

模式名簡單描述截取過濾器(Intercepting Filter) 促進請求的預先處理和后處理前端控制器(Front Controller) 提供請求處理的集中控制器視圖助手(View Helper) 把與表示層格式化無關的邏輯封裝到助手組件復合視圖(Composite View) 從原子的子組件創建一個聚集視圖工作者服務(Service To Worker) 合并分發者組件、前端控制器和視圖助手模式分發者視圖(Dispatcher View) 合并分發者組件、前端控制器和視圖助手模式，把許多動作推遲到視圖處理表二：業務層模式

模式名簡單描述業務委托(Business Delegate) 把表示層和服務層分隔開，并且提供服務的外觀和代理接口值對象(Value Object) 通過減少網絡對話，以加速層之間的數據交換會話外觀(session Facade) 隱藏業務對象復性，集中化工作流處理復合實體(Composite Entity) 通過把參數相關的對象分組進單個實體bean，表示設計粗粒度實體bean的最好經驗值對象組裝器(Value Object Assembler) 把來自多個數據源的值對象組裝成一個復合值對象值列表處理器(Value List Handler) 治理查詢執行、結果緩沖、以及結果處理服務定位器(Service Locator) 封裝業務服務查找和創建的復雜性，定位業務服務工廠表三：集成層模式

模式名簡單描述數據訪問對象(Data access Object) 抽象數據源，提供對數據的透明訪問服務激發器(Service Activator) 加速EJB組件的異步處理
由于J2EE模式眾多，篇幅有限，這里只概要介紹其中的一種應用模式 - 集成層的數據訪問對象(DAO)模式，有愛好的讀者可以參看下面參考文獻中的資料。數據訪問對象模式1、問題根據數據源不同，數據訪問也不同。根據存儲的類型(關系數據庫、面向對象數據庫等)和供給商不同，持久性存儲(比如數據庫)的訪問差別也很大。當業務組件(如會話bean)或表示組件(如助手組件)需要訪問某數據源時，它們可以使用合適的API來獲得連接性，以及操作該數據源。但是在這些組件中包含連接性和數據訪問代碼會引入這些組件及數據源實現之間的緊密耦合。組件中這類代碼依靠性使應用程序從某種數據源遷移到其它種類的數據源將變得非常麻煩和困難，當數據源變化時，組件也需要改變，以便于能夠處理新類型的數據源。2、解決方案使用數據訪問對象(DAO)來抽象和封裝所有對數據源的訪問。DAO治理著與數據源的連接以便于檢索和存儲數據，DAO實現了用來操作數據源的訪問機制。依靠于DAO的業務組件為其客戶端使用DAO提供了更簡單的接口，DAO完全向客戶端隱藏了數據源實現細節。由于當低層數據源實現變化時，DAO向客戶端提供的接口不會變化，所以該模式答應DAO調整到不同的存儲模式，而不會影響其客戶端或業務組件。重要的是，DAO充當組件和數據源之間的適配器。3、實現策略通過調整抽象工廠(Abstract Factory)模式和工廠方法(Factory Method，這二個創建型模式的實現詳情可參看GoF的<設計模式>一書)模式，DAO模式可以達到很高的靈活度。當低層存儲不會隨著實現變化而變化時，可以使用工廠方法模式來實現該策略，以產生應用程序需要的大量DAO，如下面類圖1所示。

當低層存儲隨著實現的變化而變化時，策略可以通過使用抽象工廠模式而實現。抽象工廠可以基于工廠方法實現而創建，并可使用工廠方法實現，該策略提供一個DAO的抽象工廠對象，其中該對象可以構造多種類型的具體的DAO工廠，每個工廠支持一種不同類型的持久性存儲實現。一旦你獲取某特定實現的具體DAO工廠，你可以使用它來生成該實現中所支持和實現的DAO，如下面類圖2所示。 4、應用當數據訪問代碼被直接嵌入到有其他不相關職責的某類中時，就會使修改變的十分困難。這時可以采用分離數據訪問代碼的解決方案，將數據訪問代碼抽取到一個新類中，并且把該新類邏輯或者物理地移動到離數據源比較近的位置，這樣可以增強模塊性和可重用性，如下面圖3所示。具體作法可以使用提煉類(Extract Class，一種重構手法，細節可參看Martin的<重構>一書)方法創建一個新類，并將原來類中把數據訪問代碼移動到這個新的數據訪問對象(DAO)類，使用這個新的DAO對象從控制器類中訪問數據。示例：持久性邏輯被嵌入到一個使用新DAO對象治理的持久性的某企業新DAO對象中，把持久性代碼和該企業新DAO對象代碼結合起來會創建脆弱的、緊密耦合的代碼。當持久性代碼是該企業新DAO對象的一部分時，對該持久性存儲的任何改動都要求更改該新DAO對象的持久性代碼。這種耦合對企業新DAO對象代碼維護會帶來負面的影響。下面圖4為運用分離數據訪問對象方法對其進行重構改進后的結果。模式與J2EE（圖一）

在15個J2EE模式中，每個模式都作用于設計模式和構架模式之間的某些方面。每個模式不是孤立存在的，需要其它模式的支持才能更加體現其含義和用處，為了最大限度的用好模式，還需要充分理解模式之間的關系。參考文獻系統分析員教程 --- 羅曉沛等箸

設計模式：可復用面向對象軟件的元素 --- 李英軍等譯

重構-改善既有代碼的設計 --- 侯捷等譯

J2EE核心模式 --- 牛志奇等譯

UML精粹(第二版) --- 徐家福譯

上一篇：安全組項目質量管理經驗

下一篇：軟件工程之需求分析過程介紹