/
by Dan Malks和Deepak Alur
June
在
年的JavaOne大會上
我們推出了《J
EE核心模式》
裡面包含一個模式目錄
該模式目錄中涉及了
個J
EE的設計模式
這些模式是J
EE平台下軟件設計師和系統架構師經常遇到的典型問題及其解決方案
這本書裡面也列舉了無數糟糕的實現並對它們進行了重構
通過這些例子的學習
你可以改善你現有的設計
所有的這些模式都是在我們給客戶創建成功的J
EE應用過程中被發現並提煉出來的
模式與交流技術問題及其解決方案息息相關
他們可以讓我們記錄一些反復出現的問題及其解決方案並與其他人進行交流
寫《J
EE核心模式》的一個動力就是人們常把
學習J
EE技術
與
學習用J
EE技術進行設計
混淆起來
現存的許多Java書籍大都介紹J
EE技術的各個方面
卻幾乎沒有哪本書介紹如何應用這些技術
基於作為Sun專家服務Java中心的Java系統架構師的經驗
我們覺得我們可以填補這個空白
不過那已經是過去了
下面我們談現在
《J
EE核心模式》第一版出版以後
我們收到讀者對那
個模式大量的反饋意見
過去的幾年中
J
EE模式討論區非常活躍
注冊會員也超過
人
我們很高興能從j
eepatte收到大量讀者的直接反饋意見
這幾年中
我們又做了幾個重要的大型J
EE結構
也參與幾個項目的開發
其間我們不斷地應用這些模式
同時又總結出了另外的一些模式
基於大家的反饋以及我們在工作中取得的經驗
在
年的JavaOne大會上
我們又推出該書的第二版
原有的
個模式全部都進行了修正和更新
引進許多新的實現策略和例程
增加了有關Web服務（Web service）的內容
覆蓋了最新的J
EE
我們又引進了
個新的模式
那麼現在一共有
個J
EE設計模式
新增加的
個模式主旨在於改進模式語言
提供了高度抽象
你可以用來構造和理解J
EE應用
模式目錄
我們在第二版種引入了
個新的模式
每一層兩個
表示層模式
環境對象（Context Object）
應用控制器（Application Controller ）
業務層
應用服務（Application Service ）
業務對象（Business Object ）
集成層模式
域存儲（Domain Store）
Web服務代理（Web Service Broker ）
下面圖中顯示了模式目錄中的
個模式
圖
圖
圖
分別顯示了各層中的模式
圖
顯示了各個模式之間的關系
請注意
所有的模式都已經修正並更新過
包括了一些新的實現策略以及一些新的例程
圖
表示層模式
圖
業務層模式
圖
集成層模式
圖
各模式之間的關系
精選模式
這一部分
我們對新引進的
個模式的一小部分進行一個簡單的介紹
其他更詳細的信息
包括其他模式
實現策略
例程
UML框圖
糟糕的實現及J
EE重構等
請參考
J
EE核心模式
雖然直到現在環境對象（Context Object）才被記錄為一個模式
但是實際上我們在工作中會經常用到它
環境對象（Context Object）的使用可以提高系統的的可復用性
可維護性
可擴展性以及易測試性
下面我們介紹一下這個模式所涉及的問題
解決方案
UML類圖
UML序列圖以及使用這個模式的後果
環境對象（Context Object）
問題
你想避免在相關環境之外使用與系統特定協議有關的信息
一個應用程序總是要通過請求/響應的生命周期使用一些系統信息
比如請求信息
配置信息以及安全性數據等
這些系統信息總是與特定的處理環境有關
如果應用程序的組件或服務在該特定環境之外直接使用這些系統信息的話
那麼這些組件的靈活性和復用性就降低了
在特定環境的外部使用協議相關的API就意味著所有使用這些API的組件都被完全曝露了
並且過於暴露了細節
每一個客戶組件因而都與特定的協議緊緊綁定在一起
解決方案
創建一個環境對象
以一種與協議無關的方式封裝系統信息
然後在整個應用程序內部使用這個環境對象
如下面圖
所示
把系統信息封裝在一個環境對象中
允許程序的其它部分共享訪問
這樣就可以避免把應用同特定的協議綁定在一起
比方說
HTML form中每個域都是一個HTTP請求參數
如果使用一個環境對象以一種與協議無關的方式存儲這些數據的話
那麼數據的轉換和驗證就會變得容易一些
而且
程序的其它部分也可以直接從環境對象中訪問這些信息
不用考慮HTTP協議的問題
如果協議發生變化了
那麼只用修改環境對象就行了
應用程序的其它部分不用作任何改動
圖
環境對象（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）
圖
應用服務（Application Service）
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27338.html
