問題：
需要垮層次傳輸多種資料物件。
j2ee應用系統把伺服器端的業務元件實現為會話門面和業務物件，這些元件的一些方法需要把資料返回給客戶端。這些元件通常實現為遠端物件，比如session bean 和 entity bean 。如果這些業務元件欂櫨的是細粒度的get/set方法，客戶端為了獲得他需要的所有資料值，就必須呼叫多個getter方法。
但是這樣一來回造成效能上的瓶頸，因為ejb的每次方法呼叫都可能是遠端的。遠端呼叫產生的網路負載，及時客戶端和ejb容器在同乙個jvm、作業系統或者物理主機上。所以，如果只需要每次獲得一組資料，還要多次呼叫遠端物件的getter方法，那就是極為低效的。執行的遠端呼叫越多，應用系統也就是越囉嗦，這個應用系統的效能就是越惡化。
即使不是遠端元件，也仍然會需要訪問封裝在另乙個層次中的元件，比如業務層中的業務物件以及整合層中的資料訪問物件。雖然這些元件不是遠端物件，在傳送、獲取資料的時候，仍然應該通過粗粒度的介面訪問他們。
約束：要讓客戶端訪問其他層中的元件，從而獲取並更新資料。
要減少網路中的遠端請求。
要避免囉嗦的，高網路負載的應用系統造成的網路效能惡化。
解決方案：
使用傳輸物件垮層次傳輸多種資料元素。
設計傳輸物件，就是要優化跨層次的資料傳輸。這樣就可以不再逐個傳輸單獨的資料元素，而是用乙個傳輸物件，以單一的結構盛放請求或者響應需要的所有的資料元素。
傳輸物件按值傳送給客戶端，所以，對傳輸物件的所有呼叫都是作用於原始物件的拷貝上。
J2EE表現層模式 context物件
問題 不想在協議無關的環境上下文中使用針對特定協議的系統資訊。在請求和響應的整個生命週期中，乙個應用系統通常要使用系統資訊，比如請求 配置 安全資料等等。系統資訊的獲取方式與環境的上下文相關。當負責業務應用的元件和服務必須使用一些處於他們環境上下文之外的系統資訊時，這些元件的靈活性和可重用性都會下降...
J2EE業務層模式 值列表處理器
問題 遠端客戶端要遍歷乙個很大的結果列表。很多j2ee應用系統都會讓客戶端執行各種查詢。這些查詢經常從表現層開始，有業務層執行，最後顯示在瀏覽器中。可以用很多方法來完成查詢。如果是entity bean 實現的業務物件，可以用entity bean 的finder方法。如果沒有用entity bea...
J2EE常用設計模式 工廠模式
軟體設計的一般原則 1.開閉原則 對擴充套件開放，對修改關閉 2.黎克特制代換原則 在任何基類出現的地方，子類一定可以出現 3.依賴倒轉原則 依賴於抽象，不依賴於實現 4.介面隔離原則 應當為客戶提供盡可能小的單獨的介面而不是大的總介面 5.組合，聚合復用原則 盡量使用組合聚合而不是使用繼承達到 復...