問題：
不想在協議無關的環境上下文中使用針對特定協議的系統資訊。
在請求和響應的整個生命週期中，乙個應用系統通常要使用系統資訊，比如請求、配置、安全資料等等。系統資訊的獲取方式與環境的上下文相關。當負責業務應用的元件和服務必須使用一些處於他們環境上下文之外的系統資訊時，這些元件的靈活性和可重用性都會下降。所以，在相關的環境上下文之外使用乙個特定協議的api，這就會把特定的就介面和處理細節暴露給使用這個api的所有元件。這樣，所有作為api的客戶的元件也就和那個特定的協議產生了緊耦合。
比如說，web元件接受http協議的請求。但是，如果讓表現層和其他層次的元件共享這些http請求，這就會吧協議的細節暴露給所有這樣的元件。如果協議本身或者其中某個細節改變了，比如說，如果表單的某個元素或者欄位名稱變了；那麼所有的客戶端**也必須變化。
約束：--元件和服務要訪問系統資訊
--要解除系統資訊的協議細節與業務應用元件/服務之間的耦合
--只想在特定的環境上下文中暴露與協議先關的api
解決方案：
使用context物件，按照協議無關的方式封裝狀態，然後在整個應用系統中使用這種封裝後的物件。
用context物件封裝系統資料，就可以讓應用系統的其他部分也能使用這樣的資料，同時也不避免在應用系統和特定的協議之間造成耦合。
比如，html表單中的每個字段對應於http請求中的乙個引數；context物件可以按照協議無關的方式儲存這種資料，同時也便於資料的轉換和驗證。應用系統的其他部分可以直接通過這個context物件來訪問這些資料，並不需要http協議有任何知識。如果協議發生了任何變化，都可以交給這個context物件處理，系統的其他部分無需改動。
既然減少了對特定協議的依賴，那麼也就更加方便測試，很容易在一種更加通用的環境下進行測試，減少了對特定的容器的依賴，比如，可以用context物件包裝httpservletrequest，這樣就可以在web容器之外輕鬆地使用這個context物件進行測試。為了滿足需要，可以讓這個context物件裝載假資料，而無需包含httpserlvetrequest物件，使用了context物件，還能將狀態抽象出來，形成在不同層次間共享的資料結構，從而有助於對業務層隱藏表現層的實現細節。context物件對於協議是中立的，它所提供的松耦合特性能夠增進應用系統的可重用性和可維護性。
使用了context物件，就引發了傳輸物件之間的關係的問題。傳輸物件在遠端的層次之間傳輸狀態。雖然在傳輸資料的目的上，context物件和傳輸物件的目的一致，但是context物件共享的還是系統的資料，從而增進應用系統的可重用性和可維護性。
通過這種方式，context物件減少了原本不相關的系統元件和業務應用元件之間的耦合。傳輸物件往往封裝的是業務資料，而context物件體現的則是底層狀態。
J2EE設計模式讀書筆記（1） 表現層模式
表現層模式 裝飾器 動態新增功能到前端控制器,filter 前端控制器 建立乙個統一的集中的元件來執行公共的功能 截獲所有請求,struts mvc 將表達層分解為自包含的可重用的幾個部分,struts 復合檢視 根據幾個可重用的子檢視建立乙個試圖,tiles 服務工作者 將導航功能從前端控制器中解...
J2EE業務層模式 傳輸物件
問題 需要垮層次傳輸多種資料物件。j2ee應用系統把伺服器端的業務元件實現為會話門面和業務物件，這些元件的一些方法需要把資料返回給客戶端。這些元件通常實現為遠端物件，比如session bean 和 entity bean 如果這些業務元件欂櫨的是細粒度的get set方法，客戶端為了獲得他需要的所...
J2EE常用設計模式 工廠模式
軟體設計的一般原則 1.開閉原則 對擴充套件開放，對修改關閉 2.黎克特制代換原則 在任何基類出現的地方，子類一定可以出現 3.依賴倒轉原則 依賴於抽象，不依賴於實現 4.介面隔離原則 應當為客戶提供盡可能小的單獨的介面而不是大的總介面 5.組合，聚合復用原則 盡量使用組合聚合而不是使用繼承達到 復...