J2EE Design Pattern : Application Controller筆記

J2EE Design Pattern : Application Controller筆記

正體中譯與整理 : Fred Wang (http://fredwang.blogspot.com)
內容來源 : "Core J2EE Design Pattern"

這個Pattern用來解決甚麼問題?
. 將Action與View的管理集中化與模組化

在展示層中在接收到需求後有兩件主要的工作 :
. 第一, 收到的需求由特定的Action來提供服務, 稱為Action Management
. 第二, 控制權轉交給適當的View, 稱為View Management

這些也可以集中在Front Controller處理, 但是當應用系統及程式複雜時，最好將這些行為移到不同的classes以提高程式的模組化，重用性及擴充性。

重點:
. 重用(reuse)action與view management的程式碼
. 提升需求控管的可擴充性, 例如逐漸將Use case的功能加到應用系統內。
. 提升程式碼的模組化及可維護性, 更容易擴充您的應用系統, 更容易測試你每一部份的需求控管程式, 而這些程式與Web Container是不相關的(與Web Contrainer相關的需求管控在Front Controller完成)。

解決方案 :
- 使用一個Application Controller集中需求處理元件(如Commands與Views)的擷取與呼叫
註 : 真正處理需求及展現結果的元件不是Application Controller, 而是Commands與Views, Application Controller可以視為根據需求找到對應處理的Command(或Action), 並分派給合適的View來處理要呈現的結果。

將這些程式碼從Front Controller分離的好處有 :
1. 從Front Controller中與特定網路協定相關的程式碼分離以提升程式模組化與重用性, 例如特定的application controller元件可以提供給許多的channels(如web application與web service)重複使用來控管需求。這些控管有資料驗證(Validation), error handling, authentication, 存取控制(access control)等。
2. 與Servlet-based Front Controller分離以便於在Web container外進行測試
註 : Application Controller內部會有與Servlet及Web Container有關的API呼叫, 因此, 程式設計師進行這部份功能的單元測試就不一定要與未來執行環境相同(不需用相同的Web Container)

Pattern內的成員及責任
. Client(需求端) : 負責呼叫Application Controller, 通常維Front Controller或Intercepting Filter

. Application Controller : 使用Mapper解決收到的需求及對應的Action及View之間委派(Delegate)或分派(Dispatch)
註 : Delegate與Dispatch不同, Delegate只是將部分工作委派特定對象處理, 但控制權還在本身, 但Dispatch則是將控制權交給分派的對象。

. Mapper : 使用Map來轉譯收到的需求為合適的action和view, 可視為工廠(factory)

. Map : 放置目標資源的參考關係, 可能是Class或registry。
註 : 直接控管方式是直接可從Map中取出參考關係, 而間接控管方式是Map內包含物件, 須透過此物件才可找到目標資源。

以Jakarta Struts為例, Command Factory將request與action對應的關係從struts-config.xml中找出來, 傳回Command Map(ActionMapping)物件。這裡的Command Factory就是Mapper, ActionMappig就是Map。




參考 : http://www.corej2eepatterns.com/Patterns2ndEd/ApplicationController.htm