問題：
遠端客戶端要遍歷乙個很大的結果列表。
很多j2ee應用系統都會讓客戶端執行各種查詢。這些查詢經常從表現層開始，有業務層執行，最後顯示在瀏覽器中。
可以用很多方法來完成查詢。如果是entity bean 實現的業務物件，可以用entity bean 的finder方法。如果沒有用entity bean ，那麼通常就會使用資料訪問物件執行查詢。當查詢只返回乙個很小的結果集的時候，不會出現什麼問題。但是查詢返回了大量匹配的entity bean ，那麼entity bean 的finder方法的效率就會很低了。
另乙個問題在於，也許客戶端沒有處理大型結果集的能力，所以就要由伺服器來處理結果，客戶端往往都不會使用查詢的全部結果，所以在檢視，使用了一部分結果之後，剩下的也就拋下不用了。比如使用者可能用瀏覽器執行一次查詢，檢視了開頭的幾條結果，拋下了剩下的結果，有執行另一次查詢了。
所以，通常不需要把整個的查詢結果都返回還給客戶端，如果客戶端只顯示了前幾條結果，然後就拋下了這次查詢，那麼網路的頻寬沒有浪費，因為資料可以再伺服器那裡快取著，可能永遠也不會送到客戶端。
約束：需要避免使用ejb finder方法來處理大型的查詢造成的負載。
需要實現一種唯讀用例，這種用例不需要事務
需要為客戶端提供一種機制，能夠高效率的進行查詢，並且遍歷乙個大型的結果集
需哎喲在伺服器端維護查詢結果
解決方案：
使用值列表處理器來執行查詢、快取結果、並且讓客戶端遍歷、選擇查詢查詢結果。
值列表處理器提供了查詢和迭代的功能。為了完成這一一次查詢，值列表處理器使用個資料訪問物件執行查詢，從資料庫獲取匹配的結果。即使應用系統使用了entity bean 實現業務物件，本模式也避免使用ejb finder方法。
J2EE業務層模式 傳輸物件
問題 需要垮層次傳輸多種資料物件。j2ee應用系統把伺服器端的業務元件實現為會話門面和業務物件，這些元件的一些方法需要把資料返回給客戶端。這些元件通常實現為遠端物件，比如session bean 和 entity bean 如果這些業務元件欂櫨的是細粒度的get set方法，客戶端為了獲得他需要的所...
J2EE表現層模式 context物件
問題 不想在協議無關的環境上下文中使用針對特定協議的系統資訊。在請求和響應的整個生命週期中，乙個應用系統通常要使用系統資訊，比如請求 配置 安全資料等等。系統資訊的獲取方式與環境的上下文相關。當負責業務應用的元件和服務必須使用一些處於他們環境上下文之外的系統資訊時，這些元件的靈活性和可重用性都會下降...
J2EE常用設計模式 工廠模式
軟體設計的一般原則 1.開閉原則 對擴充套件開放，對修改關閉 2.黎克特制代換原則 在任何基類出現的地方，子類一定可以出現 3.依賴倒轉原則 依賴於抽象，不依賴於實現 4.介面隔離原則 應當為客戶提供盡可能小的單獨的介面而不是大的總介面 5.組合，聚合復用原則 盡量使用組合聚合而不是使用繼承達到 復...