【文章內容簡介】 輸對象是通過值傳遞而交送給用戶的，所以所有對于該傳輸對象的調用或取值都是本地調用，而不是遠程方法調用。不過需要注意的是，這個傳輸對象必須具有對應于每個屬性的訪問方法，或者將所有屬性都設為公共的。 類圖13表示了傳輸對象模式的體系結構。 圖13 傳輸對象類圖在圖13中，傳輸對象首先在EJB中創(chuàng)建，然后返回給遠程客戶；當然，傳輸對象也可以根據(jù)需要融合其他的設計模式。 圖14顯示了傳輸對象模式中的參與模塊和它們之間的交互。圖14 傳輸對象序列圖 下面我們說明一下傳輸對象模式的各個參與模塊： (1)客戶(Client)?？蛻舸砹薊JB所提供服務的使用者，通常是運行于用戶終端的應用程序。 (2)業(yè)務對象。業(yè)務對象表示在一個模式中由會話bean、實體bean或數(shù)據(jù)訪問對象(Data Access Object)實現(xiàn)的角色。業(yè)務對象通常負責創(chuàng)建傳輸對象，并根據(jù)請求將其傳送到相關的用戶；業(yè)務對象也可以從用戶中取得一個傳輸對象格式的數(shù)據(jù)，并應用這些數(shù)據(jù)來執(zhí)行一些更新。 (3)傳輸對象。傳輸對象是一個可序列化的Java對象。在這個對象的類中，通常會有一個包含所有域的構造函數(shù)，用來創(chuàng)建這個傳輸對象。 這個傳輸對象中的成員變量基本都被定義為公共，從而無需為它們提供相關的訪問方法。當然如果存在一定安全的需要，相關的成員變量也可以設為保護或私有，并且給定各自的訪問方法。由此可見，傳輸對象的設計是隨著應用系統(tǒng)的需要不同而改變的，是否將對象中的成員變量設為公共，或提供一定的訪問方法，將是一個很重要的設計問題。 通常在實現(xiàn)這個模式時，最多采取的是可更新的傳輸對象策略和多傳輸對象策略。 在可更新的傳輸對象策略中，傳輸對象不僅可以從服務于用戶的業(yè)務對象中取得相關信息和數(shù)據(jù)，還可以從業(yè)務對象中得到用戶對于數(shù)據(jù)所需要進行的改變。 圖15以類圖表的形式表明了業(yè)務對象和傳輸對象之間的關系。 圖15 可更新傳輸對象類圖 業(yè)務對象創(chuàng)建了傳輸對象。而用戶通過訪問業(yè)務對象，既得到了所需的信息，也對相關數(shù)據(jù)做出了一定的修改；為了能夠使得用戶可以修改業(yè)務對象各個域的取值，這個對象必須提供一定的變值方法，而出于對Web負擔的考慮，業(yè)務對象所提供的方法最好以傳輸對象為參數(shù)。相應地，這些方法可以去調用傳輸對象所提供的方法，來設置傳輸對象的各個成員變量的取值；同時在傳輸對象的方法中，我們也可以植入數(shù)據(jù)驗證和完整性檢查的邏輯，這樣在用戶從業(yè)務對象的方法得到傳輸對象時，可以直接調用傳輸對象的成員方法進行本地數(shù)據(jù)訪問，當然這種本地數(shù)據(jù)訪問不會影響到業(yè)務對象。 當用戶調用業(yè)務對象的變值方法時，該方法會將用戶端的傳輸對象序列化，再將它發(fā)送給業(yè)務對象；業(yè)務對象接收到更新的傳輸對象，便將這些更新寫回到自己的對象拷貝中去； 這里需要說明的是，上面提到的寫回只是涉及到被更新的變量，而不是全部變量的寫回，因此我們需要在傳輸對象中另設置一個變量，來指定哪些成員變量被用戶更新過，這也就使得這種模式的設計相對復雜，開發(fā)人員需要考慮同步化和版本控制的問題。圖16顯示了這個更新過程的序列圖。圖16 可更新傳輸對象序列圖 多傳輸對象的方法是指一個單一的業(yè)務對象可以根據(jù)用戶請求制造多個不同的傳輸對象。也就是說，業(yè)務對象和它所創(chuàng)建的傳輸對象保持一對多的關系。類圖17表示了這種實現(xiàn)方法的各個參與模塊以及它們之間的調用關系。圖17 多傳輸對象類圖當一個用戶需要A類型的傳輸對象時，他會激活相關EJB的getDataA()方法來取得傳輸對象A；當他需要B類型的傳輸對象時，他會激活getDataB()方法來獲取傳輸對象B；依此類推。序列圖18表示了這一過程。圖18 多傳輸對象序列圖使用這種設計模式，應用系統(tǒng)的實體bean及其遠程接口會變得十分簡單。實體bean中無需再為每一個成員變量都實現(xiàn)一個set()和get()方法，并在遠程接口中實現(xiàn)相應的定義。用戶無需再進行多次的方法調用來取得信息和數(shù)據(jù)，所需要的只是一次方法調用以獲得整個傳輸對象。當然這里需要考慮Web負擔和大量數(shù)據(jù)一次傳輸?shù)臋嗪狻ｉ_發(fā)人員可以根據(jù)不同的需要來選擇不同的實現(xiàn)方法。 如上所述，用戶和實體bean之間可以通過在一次方法調用中使用傳輸對象而交換所有的數(shù)據(jù)，也就是說傳輸對象作為數(shù)據(jù)載體工作，并減少了遠程的方法調用，從而大大減輕了Web負擔。通過使用傳輸對象的方法，我們也將有可能減少實體bean和其傳輸對象間的代碼重復。不過在使用可更新的傳輸對象方法時，用戶可以修改其本地的傳輸對象，之后再將其傳送回業(yè)務對象中，后者將所需的更新整合到自己一端；但是這樣一來，就會存在一個版本控制的問題，不同的客戶可能在同時修改相同類型的傳輸對象，而如果相關的業(yè)務對象沒有發(fā)現(xiàn)這一點的話，可能就會造成一些用戶的數(shù)據(jù)沒有得到及時更新，而另外一些用戶的數(shù)據(jù)又被覆蓋的情況；在系統(tǒng)設計中必須考慮這個問題。截取過濾器截取過濾器(intercepting filter)主要用于對于用戶請求的之前處理和之后處理，也就是說它對于客戶的請求使用了額外的操作。比如說，servlet可以處理一個網(wǎng)站的所有客戶請求并提供一個核心的認證機制。這種模式主要工作于表示層，負責處理不同類型的請求，同時也需要進行多種不同的處理。在這些請求中，有一些請求會直接傳送給后端模塊處理，而另外一些請求則先會在過濾器里解釋或補充內容，之后才能傳送給后端模塊。這種模式的提出主要是由于一個客戶的Web訪問和系統(tǒng)響應都需要一定的預處理和后處理，例如用戶身份、用戶環(huán)境信息、用戶請求的合法性等。通常這些處理的結果都會決定用戶的請求是否能夠進行，或是系統(tǒng)的響應應該用什么格式來表示。對于這種預處理和后處理問題，傳統(tǒng)上，開發(fā)人員會設計一系列額外的檢測程序模塊，也就是一整套if/else語句，并且指定如果其中任何一個檢測失敗，所有的處理工作都會退出。顯然，這種方法是存在很大弊端的，即代碼的可讀性、可維護性都會被大大降低，同時將檢測工作融于一般的程序模塊，使得整個程序的模塊性難以保證。解決這種問題的關鍵在于，設計一種簡單的技術，以能夠添加或移除額外處理的模塊，而這些模塊通常都能夠完成一定的檢測和過濾功能。根據(jù)以上的討論，J2EE研究人員提出了設計模式截取過濾器作為解決方案，這種模式可以在不影響核心處理模塊的情況下，實現(xiàn)可插入的過濾器來執(zhí)行一般的處理功能。從理論上來說，這種過濾器可以截取客戶請求和系統(tǒng)響應，并進行相應的預處理和后處理；同時開發(fā)人員也可以隨時根據(jù)需要移除這些過濾器，并不用擔心會改變任何其他模塊。我們這里所說的預處理和后處理功能，通常是指一些基本的系統(tǒng)服務，如安全、登錄，系統(tǒng)調試等。執(zhí)行這些功能的過濾器通常是需要與核心模塊分開的，并且由于系統(tǒng)職能或規(guī)則的變化，這些模塊隨時可能被添加或刪除。下面提供一些關于截取過濾器的圖示，以幫助大家更好地理解這種設計模式，并合理地加以運用。圖19表示了截取過濾器模式的整體結構，圖19顯示了截取過濾器中的參與模塊和相互之間的聯(lián)系。 圖19 截取過濾器模式 圖20 截取過濾器序列圖下面我們分別來說明圖20中的各個模塊：(1)過濾管理器(Filter Manager)。過濾管理器負責過濾器的主要處理工作，即創(chuàng)建過濾器鏈對象以及相應的過濾器組建，并初始化整個處理過程。(2)過濾器鏈(Filter Chain)。過濾器鏈是一組互不依賴的過濾器有序集合。(3)過濾器1，過濾器2，過濾器3(FilterOne，F(xiàn)ilterTwo，F(xiàn)ilterThree)。這些都是提供不同服務的過濾器，而過濾器鏈則負責它們的協(xié)調工作。通過采用這種設計模式，應用系統(tǒng)可以取得更方便的中心控制，這是由于過濾器可以提供處理多種請求的中心模塊，并能根據(jù)后端的處理模塊而解釋和潤色用戶的請求，使得該請求能更好地與處理模塊所提供的功能匹配。另外，過濾器通?？梢詫⒉煌N類的服務聚集在一起，并提供相當靈活的服務組合，應用系統(tǒng)可以通過使用截取過濾器提高其重用性，過濾器可以隨時根據(jù)需要從其他程序模塊中插入或移除，并且由于它們通常具有標準的接口，開發(fā)人員可以使用一組類似的過濾器，并在不同的情況下進行全組的重用。 采用這種設計模式也會帶來一定的問題，即在過濾器之間共享信息將變得非常困難，這是由于根據(jù)其定義和需求，每個過濾器的設計和開發(fā)都大相徑庭。因而如果在不同的過濾器之間需要共享信息的話，其代價將是非常昂貴的。模式與J2EE建立于Java編程語言和Java技術基礎之上的J2EE平臺是最適用于企業(yè)級分布式環(huán)境的應用結構，它被設計為面向多層體系的結構。J2EE包含下面關鍵技術：Java服務器頁面(Java Service Page，JSP)、Servlet、Enterprise JavaBeans(EJB)組件、Java消息服務(Java Message Service，JMS)、JDBC和Java命名與目錄接口(Java Naming and Directory Interface，JNDI)。由于J2EE平臺是分層系統(tǒng)，所以我們將J2EE的層次模型化，這個模型使得我們將職責邏輯地分到不同的層中，共分了五個層次：客戶層、表示層、業(yè)務層、集成層和資源層。因為客戶層和資源層并不是J2EE平臺直接關注的問題，所以后面介紹的15個J2EE應用模式全部屬于上面五層中的中間三層，其中表示層模式包含與Servlet和JSP技術相關的模式、業(yè)務層模式包含與EJB技術有關的模式、集成層模式包含與JMS和JDBC有關的模式。具體模式可參看下面表格：表一：表示層模式 模式名簡單描述截取過濾器(Intercepting Filter)促進請求的預先處理和后處理前端控制器(Front Controller)提供請求處理的集中控制器視圖助手(View Helper)把與表示層格式化無關的邏輯封裝到助手組件復合視圖(Composite View)從原子的子組件創(chuàng)建一個聚集視圖工作者服務(Service To Worker)合并分發(fā)者組件、前端控制器和視圖助手模式分發(fā)者視圖(Dispatcher View)合并分發(fā)者組件、前端控制器和視圖助手模式，把許多動作推遲到視圖處理表二：業(yè)務層模式模式名簡單描述業(yè)務委托(Business Delegate)把表示層和服務層分隔開，并且提供服務的外觀和代理接口值對象(Value Object)通過減少網(wǎng)絡對話，以加速層之間的數(shù)據(jù)交換會話外觀(Session Facade)隱藏業(yè)務對象復性，集中化工作流處理復合實體(Composite Entity)通過把參數(shù)相關的對象分組進單個實體bean，表示設計粗粒度實體bean的最好經(jīng)驗值對象組裝器(Value Object Assembler)把來自多個數(shù)據(jù)源的值對象組裝成一個復合值對象值列表處理器(Value List Handler)管理查詢執(zhí)行、結果緩沖、以及結果處理服務定位器(Service Locator)封裝業(yè)務服務查找和創(chuàng)建的復雜性，定位業(yè)務服務工廠表三：集成層模式模式名簡單描述數(shù)據(jù)訪問對象(Data Access Object)抽象數(shù)據(jù)源，提供對數(shù)據(jù)的透明訪問服務激發(fā)器(Service Activator)加速EJB組件的異步處理 由于J2EE模式眾多，篇幅有限，這里只概要介紹其中的一種應用模式 集成層的數(shù)據(jù)訪問對象(DAO)模式，有興趣的讀者可以參看下面參考文獻中的資料。數(shù)據(jù)訪問對象模式數(shù)據(jù)訪問對象模式問題 根據(jù)數(shù)據(jù)源不同，數(shù)據(jù)訪問也不同。根據(jù)存儲的類型(關系數(shù)據(jù)庫、面向對象數(shù)據(jù)庫等)和供應商不同，持久性存儲(比如數(shù)據(jù)庫)的訪問差別也很大。當業(yè)務組件(如會話bean)或表示組件(如助手組件)需要訪問某數(shù)據(jù)源時，它們可以使用合適的API來獲得連接性，以及操作該數(shù)據(jù)源。但是在這些組件中包含連接性和數(shù)據(jù)訪問代碼會引入這些組件及數(shù)據(jù)源實現(xiàn)之間的緊密耦合。組件中這類代碼依賴性使應用程序從某種數(shù)據(jù)源遷移到其它種類的數(shù)據(jù)源將變得非常麻煩和困難，當數(shù)據(jù)源變化時，組件也需要改變，以便于能夠處理新類型的數(shù)據(jù)源。解決方案 使用數(shù)據(jù)訪問對象(DAO)來抽象和封裝所有對數(shù)據(jù)源的訪問。DAO管理著與數(shù)據(jù)源的連接以便于檢索和存儲數(shù)據(jù)，DAO實現(xiàn)了用來操作數(shù)據(jù)源的訪問機制。依賴于DAO的業(yè)務組件為其客戶端使用DAO提供了更簡單的接口，DAO完全向客戶端隱藏了數(shù)據(jù)源實現(xiàn)細節(jié)。由于當?shù)蛯訑?shù)據(jù)源實現(xiàn)變化時，DAO向客戶端提供的接口不會變化，所以該模式允許DAO調整到不同的存儲模式，而不會影響其客戶端或業(yè)務組件。重要的是，DAO充當組件和數(shù)據(jù)源之間的適配器。實現(xiàn)策略 通過調整抽象工廠(Abstract Factory)模式和工廠方法(Factory Method，這二個創(chuàng)建型模式的實現(xiàn)詳情可參看GoF的設計模式一書)模式，DAO模式可以達到很高的靈活度。 當?shù)蛯哟鎯Σ粫S著實現(xiàn)變化而變化時，可以使用工廠方法模式來實現(xiàn)該策略，以產生應用程序需要的大量DAO，如下面類圖1所示。 當?shù)蛯哟鎯﹄S著實現(xiàn)的變化而變化時，策略可以通過使用抽象工廠模式而實現(xiàn)。抽象工廠可以基于工廠方法實現(xiàn)而創(chuàng)建，并可使用工廠方法實現(xiàn)，該策略提供一個DAO的抽象工廠對象，其中該對象可以構造多種類型的具體的DAO工廠，每個工廠支持一種不同類型的持久性存儲實現(xiàn)。一旦你獲取某特定實現(xiàn)的具體DAO工廠，你可以使用它來生成該實現(xiàn)中所支持和實現(xiàn)的DAO，如下面類圖2所示。應用 當數(shù)據(jù)訪問代碼被直接嵌入到有其他不相關職責的某類中時，就會使修改變的十分困難。這時可以采用分離數(shù)據(jù)訪問代碼的解決方案，將數(shù)據(jù)訪問代碼抽取到一個新類中，并且把該新類邏輯或者物理地移動到離數(shù)