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的开发将有很 好的借鉴意义。