JavaOne大會發布《J2EE核心模式》第二版

2019-11-18 12:18:03

字體：大中小

來源：轉載

供稿：網友

　　http://developer.java.sun.com/developer/technicalArticles/J2EE/J2EEevolution/
　　by Dan Malks和Deepak Alur
　　June 2003
　　
　　
　　
　　在2001年的JavaOne大會上，我們推出了《J2EE核心模式》，里面包含一個模式目錄，該模式目錄中涉及了15個J2EE的設計模式。這些模式是J2EE平臺下軟件設計師和系統架構師經常碰到的典型問題及其解決方案。這本書里面也列舉了無數糟糕的實現并對它們進行了重構，通過這些例子的學習，你可以改善你現有的設計。所有的這些模式都是在我們給客戶創建成功的J2EE應用過程中被發現并提煉出來的。
　　
　　
　　
　　模式與交流技術問題及其解決方案息息相關，他們可以讓我們記錄一些反復出現的問題及其解決方案并與其他人進行交流。寫《J2EE核心模式》的一個動力就是人們常把“學習J2EE技術”與“學習用J2EE技術進行設計”混淆起來。現存的許多Java書籍大都介紹J2EE技術的各個方面，卻幾乎沒有哪本書介紹如何應用這些技術?；谧鳛镾un專家服務Java中心的Java系統架構師的經驗，我們覺得我們可以填補這個空白。
　　
　　
　　
　　不過那已經是過去了，下面我們談現在
　　
　　
　　
　　《J2EE核心模式》第一版出版以后，我們收到讀者對那15個模式大量的反饋意見。過去的幾年中，J2EE模式討論區非常活躍，注冊會員也超過2000人。我們很興奮能從j2eepatterns-feedback@sun.com收到大量讀者的直接反饋意見。這幾年中，我們又做了幾個重要的大型J2EE結構，也參與幾個項目的開發，其間我們不斷地應用這些模式，同時又總結出了另外的一些模式。
　　
　　
　　
　　基于大家的反饋以及我們在工作中取得的經驗，在2003年的JavaOne大會上，我們又推出該書的第二版。原有的15個模式全部都進行了修正和更新，引進許多新的實現策略和例程，增加了有關Web服務（Web service）的內容，覆蓋了最新的J2EE1.4。我們又引進了6個新的模式，那么現在一共有21個J2EE設計模式。新增加的6個模式主旨在于改進模式語言，提供了高度抽象，你可以用來構造和理解J2EE應用。
　　
　　
　　
　　模式目錄
　　
　　
　　
　　我們在第二版種引入了6個新的模式，每一層兩個：
　　
　　表示層模式：
　　環境對象（Context Object）
　　應用控制器（application Controller ）
　　業務層：
　　應用服務（Application Service ）
　　業務對象（Business Object ）
　　集成層模式：
　　域存儲（Domain Store）
　　Web服務代理（Web Service Broker ）
　　下面圖中顯示了模式目錄中的21個模式，圖1、圖2、圖3分別顯示了各層中的模式，圖4顯示了各個模式之間的關系。請注重，所有的模式都已經修正并更新過，包括了一些新的實現策略以及一些新的例程。
　　　 JavaOne大會發布《J2EE核心模式》第二版（圖一）

　　圖1：　表示層模式
　　　 JavaOne大會發布《J2EE核心模式》第二版（圖二）

　　圖2：　業務層模式
　　　 JavaOne大會發布《J2EE核心模式》第二版（圖三）

　　圖3：　集成層模式
　　　 JavaOne大會發布《J2EE核心模式》第二版（圖四）

　　圖4：　各模式之間的關系
　　精選模式
　　
　　
　　
　　這一部分，我們對新引進的6個模式的一小部分進行一個簡單的介紹。其他更具體的信息，包括其他模式、實現策略、例程、UML框圖、糟糕的實現及J2EE重構等，請參考"J2EE核心模式"。
　　
　　
　　
　　雖然直到現在環境對象（Context Object）才被記錄為一個模式，但是實際上我們在工作中會經常用到它。環境對象（Context Object）的使用可以提高系統的的可復用性、可維護性、可擴展性以及易測試性。下面我們介紹一下這個模式所涉及的問題、解決方案、UML類圖、UML序列圖以及使用這個模式的后果。
　　
　　
　　
　　環境對象（Context Object）
　　
　　
　　
　　問題
　　
　　你想避免在相關環境之外使用與系統特定協議有關的信息。
　　
　　
　　
　　一個應用程序總是要通過請求/響應的生命周期使用一些系統信息，比如請求信息、配置信息以及安全性數據等，這些系統信息總是與特定的處理環境有關。假如應用程序的組件或服務在該特定環境之外直接使用這些系統信息的話，那么這些組件的靈活性和復用性就降低了。在特定環境的外部使用協議相關的API就意味著所有使用這些API的組件都被完全曝露了，并且過于暴露了細節。每一個客戶組件因而都與特定的協議緊緊綁定在一起。
　　
　　
　　
　　解決方案
　　
　　
　　
　　創建一個環境對象，以一種與協議無關的方式封裝系統信息，然后在整個應用程序內部使用這個環境對象。
　　
　　
　　
　　如下面圖5所示，把系統信息封裝在一個環境對象中，答應程序的其它部分共享訪問，這樣就可以避免把應用同特定的協議綁定在一起。比方說，Html form中每個域都是一個HTTP請求參數，假如使用一個環境對象以一種與協議無關的方式存儲這些數據的話，那么數據的轉換和驗證就會變得輕易一些。而且，程序的其它部分也可以直接從環境對象中訪問這些信息，不用考慮HTTP協議的問題。假如協議發生變化了，那么只用修改環境對象就行了，應用程序的其它部分不用作任何改動。
　　　 JavaOne大會發布《J2EE核心模式》第二版（圖五）

　　圖5：環境對象（Context Object）的UML類圖
　　
　　結果
　　
　　提高了可復用性和可維護性
　　既然應用程序的接口獨立于特定協議，那么其中所定義的組件和子系統就更通用，可以被各種各樣的客戶端復用。
　　提高了易測試性
　　使用環境對象模式可以幫助清除與特定的Web容器或應用服務器相關的代碼。假如限制或者消除了這些依靠，可以更輕易進行測試。比如說可以使用一些自動測試工具，例如使用JUnit來進行自動測試。
　　降低了接口變化的約束
　　原來應用程序的接口接受大量的系統信息，現在使用環境對象封裝這些數據，應用程序只用接受環境對象就可以了。這樣可以降低應用程序與特定平臺的耦合度，使得以后的修改可以更輕易進行。這對于開發應用程序框架非常重要，當然對于開發通用程序也很有價值。
　　性能的降低
　　使用環境對象模式要在對象間傳遞各種數據，因而會導致一定程度性能的下降。不過性能的些微下降與使用環境對象帶來的好處，比如應用程序組件復用性提高、應用更輕易維護和修改等等比起來，實在是微不足道。
　　我們在業務層模式中新增加了兩個模式，其中之一就是應用服務（Application Service）。這個模式與普通的業務邏輯有關。因為假如使用session Façades的話，就會導致代碼重復，而假如把這些邏輯封裝在業務對象（Business Object）的話，又會導致對象數量的劇增。
　　
　　
　　
　　應用服務（Application Service）
　　
　　
　　
　　問題
　　
　　
　　
　　你想跨越幾個業務層組件和服務通過聚合來形成一個業務邏輯
　　
　　
　　
　　服務門面（Service facade），像Session Façade或者POJO Façade幾乎不包含業務邏輯，只是對外提供了一個簡單的、粗糙的接口。業務對象（Business Object）封裝了一組相關業務操作的行為。用例（Use Case）用來協調這些業務對象和服務，而應用程序則用來實現這些用例。然而，你不應該讓用例協調業務對象（Business Object）內部的行為，這樣會增加依耦合性，降低這些業務對象間的內聚力。同樣，你也不應該把業務邏輯加到服務門面（Service facade）上，因為業務邏輯在不同的門面之間潛在地復制了代碼，這樣會降低通用代碼的復用性和可維護性。
　　
　　
　　
　　解決方案
　　
　　
　　
　　使用一個應用服務（Application Service）聚合各種行為來提供一個統一的服務層。
　　
　　
　　
　　應用服務（Application Service）提供了一個實現業務邏輯的中心位置，這個業務邏輯可能封裝了各種業務對象和服務。這種實現業務邏輯的方式，可以降低業務對象間的耦合性。使用應用服務（Application Service）模式，你可以把分散的、使用底層業務對象和服務的組件封裝成為一個高級的業務邏輯。
　　
　　
　　
　　即使你的應用程序中沒有用到業務對象（Business Object），你也可以使用業務服務（Application Service）模式來提供一個統一的業務邏輯實現層。這種情況下，應用服務（Application Service）可能會包含你程序中實現不同服務必需的所有中間業務邏輯，假如要處理持久性數據的時候，可能還會包括數據訪問對象（Data access Object，DAO）。
　　 JavaOne大會發布《J2EE核心模式》第二版（圖六）