Struts2其實並不是一個陌生的Web框架，Struts2是以Webwork的設計思想為核心，吸收了Struts1的優點，因此，可以認為Struts2是Struts1和Webwork結合的產物。

簡單來說二者的區別是：   

     一個是Stuts1 ，一個是Stuts2，這是最大的區別，技術方面，Stuts1有個核心控制器，但是隻提供了一個介面，也就是execute，還要配置actionform之類的，很麻煩，所以依賴性比較強；而Stuts2是針對攔截器開發的，也就是所謂的AOP思想，可以配置多個action，用起來比較方便，但是因為請求之前的攔截器有一些注入的操作，速度相對Stuts1來說慢一點。

一、MVC簡介

      Struts2是一個相容Struts1和WebWork的MVC框架，既然，提到了MVC框架，就不得不對MVC框架做一個簡單介紹，僅限於簡單介紹，如果，想了解更多的MVC的知識可以檢視相關的文件，或者找一本Struts1的書籍，相信上面關於MVC的篇幅不會很少。言歸正傳，其實，Java目前出現的這些框架而言，其最終目的都是為了接觸耦合，不論是Spring、Hibernate或MVC框架，目的都是為了接觸耦合增加複用。MVC接觸的是View和Model間的耦合。         MVC包含三個基礎部分：Model、View和Controller，這三個部分以最小的耦合協同工作，以增加程式的可擴充套件性和可維護性。各個部分的實現技術可以總結如下：         1）Model：JavaBean、EJB的EntityBean         2）View：JSP、Struts的TagLib         3）Controller：Struts的ActionServlet、Action 概括起來MVC的優點主要有一下方面：         1）多個檢視可以對應一個模型。按MVC設計模式，一個模型對應多個檢視，可以減少程式碼的複製及程式碼的維護量，一旦模型發生改變，也易於維護         2）模型返回的資料與顯示邏輯分離。模型資料可以應用任何的顯示技術，例如，使用JSP頁面、Velocity模板或者直接產生Excel文件等         3）應用被分隔為三層，降低了各層之間的耦合，提供了應用的可擴充套件性         4）控制層的概念也很有效，由於它把不同的模型和不同的檢視組合在一起，完成不同的請求。因此，控制層可以說是包含了使用者請求許可權的概念         5）MVC更符合軟體工程化管理的精神。不同的層各司其職，每一層的元件具有相同的特徵，有利於通過工程化和工具化產生管理程式程式碼          對於MVC的概念性的東西也就廢話到此，其關鍵的地方就是各個模組的實現技術分別是什麼。 二、Struts2簡介         Struts2既然是從Struts1發展而來，但實際上Struts2與Struts1在框架的設計思想上面還是有很大的區別，Struts2是以WebWork的設計思想為核心，為什麼Struts2不沿用Struts1的設計思想，畢竟Struts1在目前的企業應用中還是有非常大的市場在的，那麼，來看下Struts1的一些缺點吧：         1）支援的表現層技術單一         2）與Servlet API嚴重耦合，這點可以從Action的Execute的方法聲明裡面就可以看的出來         3）程式碼依賴Struts1 API，有侵入性，這點可以從寫Action類和FormBean的時候看的出來，Action必須實現Struts的Action類         而Struts2之所以以WebWork的設計思想為其核心，一點就是最近WebWork的上升勢頭，再就是WebWork沒有Struts1上面的那些缺點，更符合MVC的設計思想，也更利於程式碼的複用。         基於以上介紹可以看的出，Struts2體系結構與Struts1的體系結構有很大的差別，Struts1是使用ActionServlet做為其中心處理器，Struts2則使用一個攔截器（FilterDispatcher）做為其中心處理器，這樣做的一個好處就是將Action類和Servlet API進行了分離。         Struts2的簡單處理流程如下：         1）瀏覽器傳送請求         2）中心處理器根據struts.xml檔案查詢對應的處理請求的Action類         3）WebWork的攔截器鏈自動對請求應用通用功能，例如：WorkFlow、Validation等功能         4）如果Struts.xml檔案中配置Method引數，則呼叫Method引數對應的Action類中的Method方法，否則呼叫通用的Execute方法來處理使用者請求          5）將Action類中的對應方法返回的結果響應給瀏覽器 三、Struts2與Struts1對比          1）Action類的實現方式：                Struts1的Action在實現的時候必須擴充套件Action類或者Action的子類，Struts2的Action類實現的時候可以不用實現任何類和介面，雖然Struts2中提供一個ActionSupport類，但是，不是必須的。           2）Struts1的Action類是單例模式，必須設計成執行緒安全的，Struts2則為每一個請求產生一個例項           3）Struts1的Action類依賴與Servlet API，從其execute的方法簽名可看出，execute方法有兩個Servlet的引數HttpServletRequest和HttpServletResponse，Struts2則不依賴於Servlet API           4）以為Struts1依賴於Servlet API這些Web元素，因此對Struts1的Action進行測試的時候是很困難的，需要藉助與其他的測試工具，Struts2的Action可以象測試其他的一些Model層的Service類一樣進行測試            5）Struts1的Action與View通過ActionForm或者其子類進行資料傳遞，雖然也有LazyValidationForm這樣的ActionForm的出現，但是，還是不能象其他層面那樣通過一個簡單的POJO進行資料傳遞，而Struts2將這樣的奢望變成了現實            6）Struts1綁定了JSTL，為頁面的編寫帶來方便，Struts2整合了ONGL，也可以使用JSTL，因此，Struts2下的表示式語言更加強大 四、Struts2與WebWork對比         Struts2實際上就是WebWork2.3，不過，Struts2還是與WebWork有少許的差別：         1）Struts2不再支援內建IOC容器，改用Spring的IOC容器         2）Struts2對於Webwork的一些Ajax的特性的標籤改用Dojo進行替換

SpringMVC與Struts2的比較：

機制：

spring mvc的入口是servlet，而struts2是filter（這裡要指出，filter和servlet是不同的。以前認為filter是servlet的一種特殊），這樣就導致了二者的機制不同，這裡就牽涉到servlet和filter的區別了。

效能：

spring會稍微比struts快。spring mvc是基於方法的設計，而sturts是基於類，每次發一次請求都會例項一個action，每個action都會被注入屬性，而spring基於方法，粒度更細，但要小心把握像在servlet控制資料一樣。spring3 mvc是方法級別的攔截，攔截到方法後根據引數上的註解，把request資料注入進去，在spring3 mvc中，一個方法對應一個request上下文。而struts2框架是類級別的攔截，每次來了請求就建立一個Action，然後呼叫setter getter方法把request中的資料注入；struts2實際上是通過setter getter方法與request打交道的；struts2中，一個Action物件對應一個request上下文。

引數傳遞：

struts是在接受引數的時候，可以用屬性來接受引數，這就說明引數是讓多個方法共享的。

設計思想上：

struts更加符合oop的程式設計思想， spring就比較謹慎，在servlet上擴充套件。

intercepter的實現機制：

有以自己的interceptor機制，spring mvc用的是獨立的AOP方式。這樣導致struts的配置檔案量還是比spring mvc大，雖然struts的配置能繼承，所以我覺得論使用上來講，spring mvc使用更加簡潔，開發效率Spring MVC確實比struts2高。spring mvc是方法級別的攔截，一個方法對應一個request上下文，而方法同時又跟一個url對應，所以說從架構本身上spring3 mvc就容易實現restful url。struts2是類級別的攔截，一個類對應一個request上下文；實現restful url要費勁，因為struts2 action的一個方法可以對應一個url；而其類屬性卻被所有方法共享，這也就無法用註解或其他方式標識其所屬方法了。spring3mvc的方法之間基本上獨立的，獨享request response資料，請求資料通過引數獲取，處理結果通過ModelMap交回給框架方法之間不共享變數，而struts2搞的就比較亂，雖然方法之間也是獨立的，但其所有Action變數是共享的，這不會影響程式執行，卻給我們編碼，讀程式時帶來麻煩。

總結：

Strut1目前已經很少再用，個人感覺springMVC在易用性上要優於struts2.struts2和springMVC在效能方面是不分伯仲，每個陣營都有自己的測試資料，很難說哪一個更優秀。以上資料部分摘自網路，尊重原作者版權，分享給更多的讀者。

http://blog.csdn.net/john2522/article/details/7436307

struts2不是struts1的升級，而是繼承的webwork的血統，它吸收了struts1和webwork的優勢。

先看struts的Action官方註釋（struts1.3.8原始碼）

/**  * <p>An <strong>Action</strong> is an adapter between the contents of an  * incoming HTTP request and the corresponding business logic that should be  * executed to process this request. The controller (RequestProcessor) will  * select an appropriate Action for each request, create an instance (if  * necessary), and call the <code>execute</code> method.</p>  *  * <p>Actions must be programmed in a thread-safe manner, because the  * controller will share the same instance for multiple simultaneous requests.  * This means you should design with the following items in mind: </p>  *  * <ul>  *  * <li>Instance and static variables MUST NOT be used to store information  * related to the state of a particular request. They MAY be used to share  * global resources across requests for the same action.</li>  *  * <li>Access to other resources (JavaBeans, session variables, etc.) MUST be  * synchronized if those resources require protection. (Generally, however,  * resource classes should be designed to provide their own protection where  * necessary.</li>  *  * </ul>  *  * <p>When an <code>Action</code> instance is first created, the controller  * will call <code>setServlet</code> with a non-null argument to identify the  * servlet instance to which this Action is attached. When the servlet is to  * be shut down (or restarted), the <code>setServlet</code> method will be  * called with a <code>null</code> argument, which can be used to clean up any  * allocated resources in use by this Action.</p>  *  * @version $Rev: 471754 $ $Date: 2005-08-26 21:58:39 -0400 (Fri, 26 Aug 2005)  *          $  */

public class Action {

//程式碼省略。。。。。。。

}

再看struts2的Action註釋（struts2.3.1.2）

package com.opensymphony.xwork2;

/**  * All actions <b>may</b> implement this interface, which exposes the <code>execute()</code> method.  * <p/>  * However, as of XWork 1.1, this is <b>not</b> 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 {

    /**      * The action execution was successful. Show result      * view to the end user.      */     public static final String SUCCESS = "success";

    /**      * The action execution was successful but do not      * show a view. This is useful for actions that are      * handling the view in another fashion like redirect.      */     public static final String NONE = "none";

    /**      * The action execution was a failure.      * Show an error view, possibly asking the      * user to retry entering data.      */     public static final String ERROR = "error";

    /**      * The action execution require more input      * in order to succeed.      * This result is typically used if a form      * handling action has been executed so as      * to provide defaults for a form. The      * form associated with the handler should be      * shown to the end user.      * <p/>      * This result is also used if the given input      * params are invalid, meaning the user      * should try providing input again.      */     public static final String INPUT = "input";

    /**      * The action could not execute, since the      * user most was not logged in. The login view      * should be shown.      */     public static final String LOGIN = "login";

    /**      * 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.      *                   <b>Note:</b> Application level exceptions should be handled by returning      *                   an error value, such as <code>Action.ERROR</code>.      */     public String execute() throws Exception;

}

 Struts1和Struts2的區別和對比: Action 類:  • Struts1要求Action類繼承一個抽象基類。Struts1的一個普遍問題是使用抽象類程式設計而不是介面，而struts2的Action是介面。  • Struts 2 Action類可以實現一個Action介面，也可實現其他介面，使可選和定製的服務成為可能。Struts2提供一個ActionSupport基類去 實現 常用的介面。Action介面不是必須的，任何有execute標識的POJO物件都可以用作Struts2的Action物件。 執行緒模式:  • Struts1 Action是單例模式並且必須是執行緒安全的，因為僅有Action的一個例項來處理所有的請求。單例策略限制了Struts1 Action能作的事，並且要在開發時特別小心。Action資源必須是執行緒安全的或同步的。 • Struts2 Action物件為每一個請求產生一個例項，因此沒有執行緒安全問題。（實際上，servlet容器給每個請求產生許多可丟棄的物件，並且不會導致效能和垃圾回收問題） Servlet 依賴:  • Struts1 Action 依賴於Servlet API ,因為當一個Action被呼叫時HttpServletRequest 和 HttpServletResponse 被傳遞給execute方法。 • Struts 2 Action不依賴於容器，允許Action脫離容器單獨被測試。如果需要，Struts2 Action仍然可以訪問初始的request和response。但是，其他的元素減少或者消除了直接訪問HttpServetRequest 和 HttpServletResponse的必要性。 可測性:  • 測試Struts1 Action的一個主要問題是execute方法暴露了servlet API（這使得測試要依賴於容器）。一個第三方擴充套件－－Struts TestCase－－提供了一套Struts1的模擬物件（來進行測試）。 • Struts 2 Action可以通過初始化、設定屬性、呼叫方法來測試，“依賴注入”支援也使測試更容易。  捕獲輸入:  • Struts1 使用ActionForm物件捕獲輸入。所有的ActionForm必須繼承一個基類。因為其他JavaBean不能用作ActionForm，開發者經常建立多餘的類捕獲輸入。動態Bean（DynaBeans）可以作為建立傳統ActionForm的選擇，但是，開發者可能是在重新描述(建立)已經存 在的JavaBean（仍然會導致有冗餘的javabean）。 • Struts 2直接使用Action屬性作為輸入屬性，消除了對第二個輸入物件的需求。輸入屬性可能是有自己(子)屬性的rich物件型別。Action屬效能夠通過 web頁面上的taglibs訪問。Struts2也支援ActionForm模式。rich物件型別，包括業務物件，能夠用作輸入/輸出物件。這種 ModelDriven 特性簡化了taglib對POJO輸入物件的引用。 表示式語言：  • Struts1 整合了JSTL，因此使用JSTL EL。這種EL有基本物件圖遍歷，但是對集合和索引屬性的支援很弱。  • Struts2可以使用JSTL，但是也支援一個更強大和靈活的表示式語言－－"Object Graph Notation Language" (OGNL).  繫結值到頁面（view）:  • Struts 1使用標準JSP機制把物件繫結到頁面中來訪問。  • Struts 2 使用 "ValueStack"技術，使taglib能夠訪問值而不需要把你的頁面（view）和物件繫結起來。ValueStack策略允許通過一系列名稱相同但型別不同的屬性重用頁面（view）。 型別轉換：  • Struts 1 ActionForm 屬性通常都是String型別。Struts1使用Commons-Beanutils進行型別轉換。每個類一個轉換器，對每一個例項來說是不可配置的。 • Struts2 使用OGNL進行型別轉換。提供基本和常用物件的轉換器。  校驗：  • Struts 1支援在ActionForm的validate方法中手動校驗，或者通過Commons Validator的擴充套件來校驗。同一個類可以有不同的校驗內容，但不能校驗子物件。 • Struts2支援通過validate方法和XWork校驗框架來進行校驗。XWork校驗框架使用為屬性類型別定義的校驗和內容校驗，來支援chain校驗子屬性  Action執行的控制：  • Struts1支援每一個模組有單獨的Request Processors（生命週期），但是模組中的所有Action必須共享相同的生命週期。  • Struts2支援通過攔截器堆疊（Interceptor Stacks）為每一個Action建立不同的生命週期。堆疊能夠根據需要和不同的Action一起使用。

一、 引言Struts的第一個版本是在2001年5月份釋出的。它的最初設想是通過結合JSP和Servlet，使Web應用的檢視和業務/應用邏輯得以清晰地分離開來。在Struts之前，最常見的做法是在JSP中加入業務和應用邏輯，或者在Servlet中通過println()來生成檢視。

自從第一版釋出以來，Struts實際上已成為業界公認的Web應用標準。它的炙手可熱也為自己帶來了改進和變更，所以不但要跟上對Web應用框架不斷變化的需求，而且要與日漸增多競爭激烈的眾多框架的特性相融合。到最後，產生了幾個下一代Struts的解決方案。其中兩個最受矚目的方案是Shale和Struts Ti。

Shale是一個基於構件的框架，並在最近成為Apache的頂級專案。而Struts Ti則是在Struts的成功經驗基礎上繼續堅持對前端控制器（Front Controller）和MVC（model-view-controller）模式進行改進。WebWork專案是在2002年3月釋出的，它對Struts式框架進行了革命性改進，引進了不少新的思想、概念和功能，但和原Struts程式碼並不相容。WebWork是一個成熟的框架，經過了好幾次重大的改進與釋出。在2005年12月，WebWork與Struts Ti宣佈合併。與此同時，Struts Ti改名為Struts Action Framework 2.0，成為Struts真正的繼承者。最後要注意的是，並不是說Struts或WebWork專案已經停止開發了。由於人們對這兩個專案的興趣仍然很高，而且也有很多開發者仍然願意使用它們，因此這兩個專案還在繼續開發中，繼續修復Bug，改進功能和繼續新增新功能。

二、 Action的區別對於有著豐富的Struts1.x開發經驗的朋友來說，都十分的清楚Action是整個Struts框架的核心內容，當然Struts2也不例外。不過，Struts1.x與Struts2的Action模型很大的區別。Struts2和Struts1.x的差別，最明顯的 就是Struts2是一個pull-MVC架構。

這是什麼意思呢？從開發者角度看，就是說需要顯示給使用者的資料可以直接從Action中獲取，而不像 Struts1.x那樣，必須把相應的Bean存到Page、Request或者Session中才能獲取。Struts1.x 必須繼承org.apache.struts.action.Action或者其子類，表單資料封裝在FormBean中。

Struts 2無須繼承任何型別或實現任何介面，表單資料包含在Action中，通過Getter和Setter獲取（如下面的ActionForStruts2的程式碼示例）。雖然，在理論上Struts2的Action無須實現任何介面或者是繼承任何的類，但是，在實際程式設計過程中，為了更加方便的實現Action，大多數情況下都會繼承com.opensymphony.xwork2.ActionSupport類，並且過載（Override）此類裡的String execute()方法。

首先，從ActionForStruts2可以看出，返回的物件不是ActionForward，而是String。如果你不喜歡以字串的形式出現在你的程式碼中，有個Helper介面Action可以以常量方式提供常見結果，如“success”、“none”、“error”、“input”和“login”。

另外，按照慣例，在Struts1.x中只有“execute”方法能呼叫Action, 但在Struts2中並非必要，任何宣告為public String methodName() 方法，都能通過配置來呼叫Action。

最後，和Struts1.x最大的革命性的不同是，Struts2處理Action過程中呼叫的方法（“execute”方法）是不帶引數的。

那如何獲取所需要的物件呢？答案是使用IoC（反轉控制，Inversion of Control)，也叫“依賴注入（Dependency Injection）”的模式（想更多地瞭解這方面資訊請看Martin Fowler的文章http://www.martinfowler.com/articles/injection.html）。Spring框架使得這個模式流行起來，然而Struts2的前身（WebWork）也同時應用上了這個模式。

三、 IoCIoC(Inversion of Control，以下譯為控制反轉），隨著Java社群中輕量級容器（Lightweight Contianer）的推廣而越來越為大家耳熟能詳。在此，無需再多費脣舌來解釋“什麼是控制反轉”和“為什麼需要控制反轉”。因為網際網路上已經有非常多的文章對諸如此類的問題作了精彩而準確的回答。

讀者可以去讀一下Rod Johnson和Juergen Hoeller合著的《Expert one-on-one J2EE Development without EJB》或Martin Fowler所寫的《Inversion of Control Containers and the Dependency Injection pattern》。眾所周知，Struts2是以Webwork 2作為基礎發展出來。而在Webwork 2.2之前的Webwork版本，其自身有一套控制反轉的實現，Webwork 2.2在Spring 框架的如火如荼發展的背景下，決定放棄控制反轉功能的開發，轉由Spring實現。

值得一提的是，Spring確實是一個值得學習的框架，因為有越來越多的開源元件（如iBATIS等）都放棄與Spring重疊的功能的開發。因此，Struts2推薦大家通過Spring實現控制反轉。

為了更好地瞭解反轉控制，下面來看一個例子，如何利用IoC在Action處理過程中可以訪問到當前請求HttpServerRequest物件。在例子中，使用的依賴注入機制是介面注入。就如其名稱一樣，介面注入需要的是已經被實現了的介面。

這個介面包含了相應屬性的setter，為Action提供值。

例子中使用了ServletRequestAware介面，如下：

public interface ServletRequestAware { public void setServletRequest(HttpServletRequest request);}

當繼承這個介面後，原本簡單的Action看起來有點複雜了，但是這時可以獲取HttpServerRequest物件來使用了。

public class IoCForStruts2 implements ServletRequestAware {

        private HttpServletRequest request;

        public void setServletRequest(HttpServletRequest request)  {

                     this.request = request; }

       public String execute() throws Exception {

           // 可以開始使用request物件進行工作了

             return Action.SUCCESS; }

}

看起來現在這些屬性是類級別的，並不是執行緒安全的，會出現問題。

其實在Struts2裡並沒有問題，因為每個請求過來的時候都會產生一個新的Action物件例項，它並沒有和其他請求共享一個物件，所以不需要考慮執行緒安全問題。

攔截器 Interceptor（以下譯為攔截器），在AOP（Aspect-Oriented Programming）中用於在某個方法或欄位被訪問之前，進行攔截然後在之前或之後加入某些操作。

攔截是AOP的一種實現策略。在Webwork的中文文件的解釋為——攔截器是動態攔截Action呼叫的物件。它提供了一種機制可以使開發者定義在一個action執行的前後執行的程式碼，也可以在一個action執行前阻止其執行。同時也提供了一種可以提取action中可重用的部分的方式。Struts1.x的標準框架中不提供任何形式的攔截器，雖一個名為SAIF的附加專案則實現了這樣的功能，但它的適用的範圍還很有限。

攔截器是Struts2的一個強有力的工具，有許多功能（feature）都是構建於它之上，如國際化、轉換器，校驗等。談到攔截器，還有一個流行的詞——攔截器鏈（Interceptor Chain，在Struts2中稱為攔截器棧Interceptor Stack）。

攔截器鏈就是將攔截器按一定的順序聯結成一條鏈。在訪問被攔截的方法或欄位時，攔截器鏈中的攔截器就會按其之前定義的順序被呼叫。

Struts 2的攔截器實現相對比較簡單。當請求到達Struts2的ServletDispatcher時，Struts 2會查詢配置檔案，並根據其配置例項化相對的攔截器物件，然後串成一個列表（list），最後一一地呼叫列表中的攔截器，Struts 2已經提供豐富多樣功能齊全的攔截器實現。

讀者可以到struts2-all-2.0.6.jar或struts2-core-2.0.6.jar包的struts-default.xml檢視關於預設的攔截器與攔截器鏈的配置。作為“框架（framework）”，可擴充套件性是不可缺少的，因為世上沒有放之四海而皆準的東西。

雖然，Struts 2為我們提供如此豐富的攔截器實現，但是這並不意味我們失去建立自定義攔截器的能力，恰恰相反，在Struts 2自定義攔截器是相當容易的一件事。

前面已經簡要介紹了 Struts2的起源，並詳細對比了Struts2和Struts1.x的差異，讀者應該對Struts2的基礎有所瞭解了——包括高層的框架概念和基礎 的請求流程，並理解Struts1.x和Struts2兩者之間在Action方面的差別，Struts2加強了對攔截器與IoC的支援，而在 Struts1.x中，這些特性是很難想象的。

同時，讀者應該明白： Struts2是WebWork的升級，而不是Struts 1.x的升級。雖然Struts 2提供了與Struts1.x的相容，但已經不是Struts1.x的升級。對於已有Struts1.x開發經驗的開發者而言，Struts1.x的開發 經驗對於Struts2並沒有太大的幫助；相反，對於已經有WebWork開發經驗的開發者而言，WebWork的開發經驗對Struts2的開發將有很 好的借鑑意義。