天天看點

Struts2中的Action

多數的mvc架構中的control層,都是一個java對象。按照慣例,我們通常會把這個層次上面的java對象統稱為action層。本篇文章,我們就來簡單介紹一下struts2中action的相關内容。 

action的定義 

傳統的mvc架構中,control層一般都是一個類似與servlet的一個java對象。因為從職責上講,control層需要完成以下的職責: 

1. 接收從web容器傳遞過來的參數,并做恰當的類型轉化 

2. 調用邏輯處理 

3. 搜集資料,并傳回到視圖 

而在這個其中的第一步和第三步,都離不開web容器中的對象的處理。 

struts2中的action,與其他傳統的mvc架構不同,使用了xwork的action來構造control層。讓我們首先來看看action的接口定義: 

Struts2中的Action

/** 

 * all actions may implement this interface, which exposes 

 * the execute() method. however, as of xwork 1.1, this is 

 * not required and is only here to assist users. you are 

 * free to create pojos that honor the same contract 

 * defined by this interface without actually implementing 

 * the interface. 

 */  

public interface action {  

    /** 

     * where the logic of the action is executed. 

     * 

     * @return a string representing the logical result of the execution. 

     *         see constants in this interface for a list of standard result values. 

     * @throws exception thrown if a system level exception occurs. 

     *                   application level exceptions should be handled by returning 

     *                   an error value, such as action.error. 

     */  

    public string execute() throws exception;  

}  

我們隻需要實作這個接口,就可以在其中編寫業務邏輯完成我們的功能。 

Struts2中的Action

public class index implements action {  

    private static final long serialversionuid = -1070481751569420550l;  

    /* (non-javadoc) 

     * @see com.opensymphony.xwork2.action#execute() 

    public string execute() throws exception {  

        // write your logic here  

        return success;  

    }  

在這個接口定義中,我們可以明顯看到與傳統的mvc架構之間的差別:struts2中的action,并不需要依賴于特定的web容器。我們看不到類似httpservletrequest,httpservletresponse等web容器相關的對象。 

而這一點,也帶來了問題: 

提問:struts2的action并不帶有任何web容器相關的對象,action又是如何工作在web容器中的呢? 

雖然struts2的action隻是一個非常普通的java對象,并不具備任何web容器的特質,但是我們需要把action放到一個更加大的環境中來看。事實上,struts2為action的執行,準備了完整的資料環境和執行環境。而這個執行環境,就保證了action在web容器中的順利運作。 

在struts2中,每個http的請求,會被發送到一個filter。而這個filter,就會針對每個請求,建立出一個代碼的執行環境,并在這個基礎上,為每個執行環境配備與之對應的資料環境,這個資料環境中的内容,就來自于web容器中的一個又一個對象。這樣,就能夠順利調用action執行代碼而無需擔心它是否運作在web容器中了。 

至于這個執行環境和資料環境到底是什麼,我們接下來會詳細講到。 

提問:struts2的action并不帶有任何web容器相關的對象,action中又如何與web容器進行通信并擷取web容器的相關對象呢? 

剛剛我們提到struts2會為每個http的請求建立一個執行環境和資料環境。其中,資料環境就成為了action擷取web容器的基礎。是以,當action需要擷取web容器的相關對象,需要通過資料環境來進行。 

struts2的action的這一個重要特性,至少能為我們帶來以下好處: 

1. 使得struts2的action非常易于測試 

如果我們完全不考慮action的執行環境,僅僅把action看作一個普通的java對象,那麼我們甚至可以直接new一個action的對象,通過執行其中的方法完成測試。這樣,我們就不需要任何的mock,來模拟web容器的環境。 

2. 結合action的執行環境,使得struts2在control這個層次上,能夠定義更加豐富的執行層次 

因為action是一個普通的java類,而不是一個servlet類,完全脫離于web容器,是以我們就能夠更加友善地對control層進行合理的層次設計,進而抽象出許多公共的邏輯,并将這些邏輯脫離出action對象本身。事實上,struts2也正是這麼做的,無論是interceptor,還是result,其實都是抽象出了action中公共的邏輯部分,将他們放到了action的外面,進而更加簡化了action的開發。 

3. 使得struts2的action看上去更像一個pojo,進而更加易于管理 

struts2的action是一個線程安全的對象。而web容器傳遞過來的參數,也會傳遞到action中的成員變量中。這樣,action看上去就更像一個pojo,進而能夠友善的被許多對象容器進行管理。比如說,你可以非常友善得把action納入到spring的容器中進行管理。 

action的生命周期 

接下來,我們再來看看struts2中的action的生命周期: 

Struts2中的Action

這張圖來自于struts2的reference,我們能夠在圖中看到許多我們不熟悉的名詞,比如actionproxy,interceptor等等。這些都是struts2的control層的重要元素,也是struts2的control層的一個階層化的展現。 

上面的這張圖基本上能夠概括了struts2的整個生命周期。接下來,我們就對action中的一些重要元素進行簡單的描述。 

action的五大元素 

在大概了解了struts2的action後,我們來重點研究一下在struts2的action周圍,為action進行服務的一些重要元素,這些元素将涵蓋action的資料環境,action的執行環境、action的排程者、action的層次結構和action的執行結果。 

actioncontext —— 資料環境 

之前我們提到了struts2的action并不是一個servlet,它是脫離了web容器的。但是對于一個web架構來說,所有的資料請求(request)和資料傳回(response)都來源于web容器,那麼action在執行的時候,如何去擷取這些資料呢? 

這個問題的答案就在于,我們需要為每個action準備一個資料環境,這個資料環境被稱之為:actioncontext。由于action是應對于一個又一個的url請求,是以actioncontext應該具備以下的特性: 

1. actioncontext應成為action與web容器之間的橋梁 

2. actioncontext中應該儲存有針對某個請求的詳細資訊 

3. actioncontext應該是一個線程安全的類對象 

interceptor —— 豐富的層次結構 

簡單回顧一下上面所提到的action的職責,我們看到,需要在action這個層面上完成的事情還不少。而完成這些職責,就需要我們對這些職責進行合理的分類和排序,将他們組織成有序的執行隊列。在struts2中,使用了一種類似責任鍊的設計模式對這些不同的職責進行分類并串聯起來,進而使得action層具備了豐富的層次結構。而在這個執行隊列中的每個元素,就被我們稱之為interceptor,也就是攔截器。 

struts2 reference 寫道

interceptors can execute code before and after an action is invoked.

攔截器是aop中的概念,它本身是一段代碼,可以通過定義“織入點”,來指定攔截器的代碼在“織入點”的前後執行,進而起到攔截的作用。正如上面struts2的reference中講述的,struts2的interceptor,其攔截的對象是action代碼,可以定義在action代碼之前或者之後執行攔截器的代碼。 

如果仔細留意一下action lifecycle圖中的interceptor和action的部分,我們可以看到,interceptor一層一層的把action包了起來。這是一個典型的堆棧結構,在代碼執行的時候,每個interceptor不僅需要文成它自身的邏輯,還通過遞歸調用負責下一個攔截器或action的調用。 

most of the framework's core functionality is implemented as interceptors. features like double-submit guards, type conversion, object population, validation, file upload, page preparation, and more, are all implemented with the help of interceptors. each and every interceptor is pluggable, so you can decide exactly which features an action needs to support.

也正如struts2的reference所說,struts2提供的絕大多數的功能支援,都通過interceptor來實作,這些interceptor可以随意進行配置,并且能夠友善的插入到程式中去運作。 

result —— 執行結果 

有執行就必然有執行的結果。在struts2中,action的執行結果被抽象成了一個層次。在這個層次中,可以定義任意類型的view層的結構。也就是說,struts2并不強制view層的表現形式,可以是jsp、freemarker模闆、二進制流輸出等等。 

struts2把執行結果抽象成一個層次,使得你可以不再關注許多視圖整合上面的細節,隻需要考慮視圖的類型和資料的準備,這樣,你也可以不必在沉浸在雜亂的構造視圖的代碼中。 

actionproxy —— 執行環境 

有了攔截器interceptor,有了action本身,也有了action的執行結果result,我們就需要一個類似排程器的産品,将這些元素整合起來,進行排程執行。在上面的action lifecyle的圖中,我們可以看到,interceptor、action和result都處于actionproxy中,是以actionproxy就成為了所有這些元素的執行環境。 

既然是執行環境,那麼actionproxy就需要提供action執行的時候一切所需要的配置、參數等等,當然,也要有進行action調用的入口。是以讓我們來看一下actionproxy的接口: 

Struts2中的Action

public interface actionproxy {  

     * called after all dependencies are set 

    void prepare() throws exception;  

     * @return the action instance for this proxy 

    object getaction();  

     * @return the alias name this actionproxy is mapped to 

    string getactionname();  

     * @return the actionconfig this actionproxy is built from 

    actionconfig getconfig();  

     * sets whether this actionproxy should also execute the result after executing the action 

     * @param executeresult 

    void setexecuteresult(boolean executeresult);  

     * @return the status of whether the actionproxy is set to execute the result after the action is executed 

    boolean getexecuteresult();  

     * @return the actioninvocation associated with this actionproxy 

    actioninvocation getinvocation();  

     * @return the namespace the actionconfig for this actionproxy is mapped to 

    string getnamespace();  

     * execute this actionproxy. this will set the actioncontext from the actioninvocation into the actioncontext 

     * threadlocal before invoking the actioninvocation, then set the old actioncontext back into the threadlocal. 

     * @return the result code returned from executing the actioninvocation 

     * @throws exception 

     * @see actioninvocation 

    string execute() throws exception;  

     * sets the method to execute for the action invocation. if no method is specified, the method provided by 

     * in the action's configuration will be used. 

     * @param method the string name of the method to invoke 

    void setmethod(string method);  

     * returns the method to execute, or null if no method has been specified (meaning "execute" will be invoked) 

    string getmethod();  

很顯然,在這其中,prepare和execute方法是用作action調用的入口函數,其他的接口定義都與action執行時的運作參數和配置有關。 

actioninvocation —— 排程者 

在上面的actionproxy的接口定義中,我們可以看到有一個比較特殊的變量:actioninvocation比較吸引我們的眼球。從字面上去了解,actioninvocation就是action的調用者。事實上也是如此,actioninvocation在這個action的執行過程中,負責interceptor、action和result等一系列元素的排程。 

在之後的章節中,這個actioninvocation類也将成為我們解讀struts2源碼的一個重要入手點。這個類将告訴你,struts2是如何通過actioninvocation來實作對interceptor、action和result的合理排程的。

原文連結:[http://wely.iteye.com/blog/2295296]