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的開發將有很 好的借鑒意義。