struts 2struts2与struts的区别

STRUTS和STRUTS2的疑问

Struts1和Struts2的区别和对比 (转自 诗意的活着) ? Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口。 ? 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和Struts2的区别和对比 (转自 诗意的活着) ? Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口。 ? 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和struts2的区别是什么？

你问的应该是 struts1 和struts2 的区别： Struts2与Struts1的对比 1，在Action实现类方面： Struts1要求Action类继承一个抽象基类；Struts1的一个具体问题是使用抽象类编程 而不是接口。Struts2 Action类可以实现一个Action接口，也可以实现其他接口，使可选和定制服务成为可能。 Struts2 提供一个ActionSupport基类 去实现常用的接口。即使Action接口不是必须实现的，只有一个包含 execute方法的POJO类都可以用作Struts2的Action。 2，线程模式方面： Struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能做的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的；Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。 3，Servlet依赖方面： Struts1 Action依赖于Servlet API，因为Struts1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。 Struts2 Action 不再依赖于ServletAPI，从而允许Action脱离Web容器运行，从而降低了测试Action的难度。当然，如果Action 需要直接访问HttpServletRequest和HttpServletResponse参数，Struts2 Action仍然可以访问它们。但是，大部分时候，Action都无需直接访问 HttpServletRequest和HttpServletResponse，从而给开发者更多灵活的选择。 4，可测试方面： 测试Struts1 Action的一个主要问题是execute方法依赖于Servlet于ServletAPI， 这使得Action 仍然的测试要依赖于Web容器。为了脱离Web容器测试Struts1 的Action， 必须借助于第三方扩展：Struts TestCase，该扩展下包含了系列的Mock对象，从而脱离Web容器测试Struts1的Action类。 Struts2Action可以通过初始化，设置属性，调用方法来测试。 5，封装请求参数方面： Struts1 使用ActionForm对象封装用户的请求参数，所有的ActionForm 必须继承一个 基类：ActionForm。 普通的JavaBean不能用作ActionForm因此，开发者必须创建大量的ActionForm类封装用户请求参数。虽然Struts1 提供了动态ActionForm 来简化ActionForm 的开发，但依然需要在配置文件中定义ActionForm； Struts2 直接使用Action 属性来封装用户请求属性，避免了开发者需要大量开发ActionForm类的繁琐，实际上，这些属性还可以是包含子属性的Rich对象类型。如果开发者依然怀念Struts1 ActionForm 的模式 Struts 2 提供了ModelDriven 模式， 可以让开发者使用单独的Model 对象来封装用户请求参数，但该Model对象无须继承任何Struts2基类，是一个POJO，从而 降低了代码污染。 6，表达式语言方面： Struts1 整合了JSTL，因此可以使用JSTL表达式语言。这种表达式语言有基本对象图遍 历，但在对集合和索引属性的支持上则功能不强 Struts2 可以是用JSTL，但它整合了一种更强大和灵活的表达 式语言：OGNL（Object Graph Notation Language）,因此，Struts2下的表达式语言功能更加强大。 7，绑定值到视图方面： Struts1 使用标准JSP机制把对象绑定到视图页面； Struts2 使用“ValueStack”技术，使标签能够访问值，而不需要把对象和视图页面绑定在一起。 8，类型转换的方面： Struts 1 ActionForm 属性通常都是String 类型。 Struts1 使用 Commons-Beanutils 进行类型转换，支持基本数据类型和常用对象之间的转换。 9，数据校验的方面： Struts1 支持在ActionForm 重写 validate方法手动校验，或者通过整合Commonsalidator框架来完成数据校验。 Struts2 支持通过重写validator方法进行校验，也支持整合XWork校验框架进行校验 10，Action执行控制的方面： Struts1 支持每一个模块对应一个请求处理（既生命周期的概念），但是模块中的所有Action必须共享相同的生命周期。 Struts2支持通过拦截器堆栈为每一个Action 创建不通的生命周期。开发者可以根据需要创建相应堆找，从而和不同的Action一起使用。

struts和struts2的区别

从Struts2的发展过程来看，Struts2继承了Struts与Webwork的特性，形成了新的框架。但是它的称呼只是在“Struts”后面添加一个“2”，显然Struts2还是更多的继承了Struts的设计思想，并加入了WebWork的特点。下面将从十个方面来说明Struts与Struts2之间的不同点： （1）Action类 在Struts中都是使用抽象类编程而不是接口，因此它要求开发的Action类继承一个抽象基类，如DispatchAction等； Struts2则基于接口编程，我们的Action类可以实现一个Action接口，也可实现其他接口，使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去实现常用的接口。更加强大的是，在Struts2中Action接口不是必需的，任何有execute()函数的POJO对象都可以用作Struts2的Action类来使用。 （2）线程模式 Struts的Action是单例模式并且是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了StrutsAction能做的事，并且要在开发时特别小心，Action资源必须是线程安全的或者同步的； Struts2的Action对象为每一个请求产生一个实例，因此没有线程安全的问题。 （3）Servlet依赖 Struts的Action依赖于ServletAPI，当一个Action被调用时，HttpServletRequest和HttpServletResponse被传递给执行的方法； Struts2的Action不依赖于容器，运行Action脱离容器单独被测试。如果需要，Struts2的Action仍然可以访问初始的request和response。 （4）可测试性 测试StrutsAction的一个主要问题是，execute()方法暴露了ServletAPI，这使得测试要依赖于容器。 Struts2Action的类是POJO类，因此可以直接编写测试类来进行测试，只需要在测试类中为Action注入属性即可。 （5）捕获输入 Struts使用ActionForm对象捕获用户输入，所有的ActionForm必须继承一个基类ActionForm。因为其他的JavaBean不能用作ActionForm，开发者经常创建多余的类捕获输入。动态表单可以作为创建传统ActionForm的选择，但是，开发者可能是在重新创建已经存在的JavaBean，仍然会导致有冗余的JavaBean； Struts2直接使用Action属性作为输入属性，消除了对第二个输入对象的需求。输入属性可能是有自己子属性的rich对象模型。Action属性能够通过Web页面上的taglibs访问。同时，Struts2也支持ActionForm模式。 （6）表达式语言 Struts整合了JSTL，这种EL有基本对象图遍历，但是对集合和索引属性的支持很弱； Struts2可以使用JSTL，但是也支持一个更强大和灵活表达式语言OGNL。 （7）绑定值到页面 Struts使用标准JSP机制把对象绑定到页面中来访问； Struts2使用ValueStack（值堆栈）技术，使taglib能够访问值，而不需要把你的页面和对象绑定起来。ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面。 （8）类型转换 Struts的ActionForm属性通常都是String类型，并使用Commons-Beanutils进行类型转换。每个类提供一个转换器，对每一个实例来说都是不可配置的； Struts2使用表达式语言OGNL进行类型转换，提供了基本和常用对象的转换器。 （9）数据校验 Struts支持在ActionForm的validate()方法中手动校验，或者通过Commons Validator的扩展来校验。同一个类可以有不同的校验内容，但不能校验子对象； Struts2支持通过validate()方法和XWork校验框架来进行校验，XWork校验框架使用属性类型定义的校验和内容校验，来支持chain校验子属性。 （10）Action执行的控制 Struts支持每一个模块有单独的Request Processors（生命周期），但是模块中的所有Action必须共享相同的生命周期； Struts2支持通过拦截器堆栈(Interceptor Stacks)为每一个Action创建不同的生命周期，堆栈能够根据需要和不同的Action一起使用。 总之，从实际开发的角度来说，Struts框架和Struts2框架的主要不同点在于Action类不同。

Struts2的工作原理，简单点说出来

struts2的工作原理，浏览器发送请求过来，前端控制器fc收到请求后根据struts.xml配置文件查找对应的action，找到后创建一个valuestack对象，该对象中包含一个root栈和一个map集合。将查找到的action实例化后将对象保存在root栈顶中。然后运行层层拦截器的代码，将结果return出去交给result去比较选择对应的jsp或action

Struts2：关于struts2的作用

作为web层框架应该大体实现以下功能: 1.获取表单内容,并组织生成参数对象 2.根据请求的参数转发请求给适当的控制器 3.在控制器中调用业务接口 4.将业务接口返回的结果包装起来发送给指定的视图,并由视图完成处理结果的展现 5.做一些简单的校验或是国际化工作 无论是登录还是上传什么,没有其他层的协助是无法实现的,当然你也可以硬编码的来实现业务逻辑或数据库操作,这样的做法扩展性和可维护性极差 hibernate是操作数据库的一种框架,它简化了直接使用jdbc api的代码操作数据库的复杂性和冗余性 spring则完全是一种架构型的框架了,它不属于J2EE应用中的任何一个层,但它提供了对象依赖注入的思想,并且为每个层中遇到的实际问题提供了大量现成的模板类,使用这些模板类的方法很easy,大多数情况下只需要你在配置文件里配置一下就可以实现诸如事务管理或安全性控制这样的复杂问题.使用spring你的代码不依赖于框架,不依赖于具体实现,而依赖于接口,这对于实现松散耦合的架构来说是大有裨益的.spring不仅仅可以用于web应用,在普通的java应用中也可以使用spring.spring不是个复杂的框架,它的核心包很小并且具有轻量级的架构,基本上spring的核心只有2个东西:Ioc & AOP,Ioc其实就是工厂模式的一种体现,而AOP则来源AOP联盟,使用了拦截的思想...学了spring,现在写起代码觉得自己就像个白痴,有什么问题直接在配置文件里配置一下相关的模板类就OK了,它是真正为程序员减轻工作负担的框架.

struts2和struts的区别？

1.Action 类: ? Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口。 ? Struts 2 Action类可以实现一个Action接口，也可实现其他接口，使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去实现 常用的接口。Action接口不是必须的，任何有execute标识的POJO对象都可以用作Struts2的Action对象。 2.线程模式: ? Struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能作的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的。 ? Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。（实际上，servlet容器给每个请求产生许多可丢弃的对象，并且不会导致性能和垃圾回收问题） 3.Servlet 依赖: ? Struts1 Action 依赖于Servlet API ,因为当一个Action被调用时HttpServletRequest 和 HttpServletResponse 被传递给execute方法。 ? Struts 2 Action不依赖于容器，允许Action脱离容器单独被测试。如果需要，Struts2 Action仍然可以访问初始的request和response。但是，其他的元素减少或者消除了直接访问HttpServetRequest 和 HttpServletResponse的必要性。 4.可测性: ? 测试Struts1 Action的一个主要问题是execute方法暴露了servlet API（这使得测试要依赖于容器）。一个第三方扩展－－Struts TestCase－－提供了一套Struts1的模拟对象（来进行测试）。 ? Struts 2 Action可以通过初始化、设置属性、调用方法来测试，“依赖注入”支持也使测试更容易。 5.捕获输入: ? Struts1 使用ActionForm对象捕获输入。所有的ActionForm必须继承一个基类。因为其他JavaBean不能用作ActionForm，开发者经常创建多余的类捕获输入。动态Bean（DynaBeans）可以作为创建传统ActionForm的选择，但是，开发者可能是在重新描述(创建)已经存在的JavaBean（仍然会导致有冗余的javabean）。 ? Struts 2直接使用Action属性作为输入属性，消除了对第二个输入对象的需求。输入属性可能是有自己(子)属性的rich对象类型。Action属性能够通过web页面上的taglibs访问。Struts2也支持ActionForm模式。rich对象类型，包括业务对象，能够用作输入/输出对象。这种ModelDriven 特性简化了taglib对POJO输入对象的引用。 6.表达式语言： ? Struts1 整合了JSTL，因此使用JSTL EL。这种EL有基本对象图遍历，但是对集合和索引属性的支持很弱。 ? Struts2可以使用JSTL，但是也支持一个更强大和灵活的表达式语言－－"Object Graph Notation Language" (OGNL). 7.绑定值到页面（view）: ? Struts 1使用标准JSP机制把对象绑定到页面中来访问。 ? Struts 2 使用 "ValueStack"技术，使taglib能够访问值而不需要把你的页面（view）和对象绑定起来。ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面（view）。 8.类型转换： ? Struts 1 ActionForm 属性通常都是String类型。Struts1使用Commons-Beanutils进行类型转换。每个类一个转换器，对每一个实例来说是不可配置的。 ? Struts2 使用OGNL进行类型转换。提供基本和常用对象的转换器。 9.校验： ? Struts 1支持在ActionForm的validate方法中手动校验，或者通过Commons Validator的扩展来校验。同一个类可以有不同的校验内容，但不能校验子对象。 ? Struts2支持通过validate方法和XWork校验框架来进行校验。XWork校验框架使用为属性类类型定义的校验和内容校验，来支持chain校验子属性 10.Action执行的控制： ? Struts1支持每一个模块有单独的Request Processors（生命周期），但是模块中的所有Action必须共享相同的生命周期。 ? Struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。堆栈能够根据需要和不同的Action一起使用。

struts2的优点是什么？

1 > Struts2没有像struts1那样跟Servlet API和struts API有着紧密的耦合，Struts2的应用可以不依赖于Servlet API和struts API。 Struts2的这种设计属于无侵入式设计，而Struts1却属于侵入式设计。 public class OrderListAction extends Action {  public ActionForward execute(ActionMapping mapping, ActionForm form,    HttpServletRequest request, HttpServletResponse response)    throws Exception {  } } 2> Struts2提供了拦截器，利用拦截器可以进行AOP编程，实现如权限拦截等功能。 3> Strut2提供了类型转换器，我们可以把特殊的请求参数转换成需要的类型。在Struts1中，如果我们要实现同样的功能，就必须向Struts1的底层实现BeanUtil注册类型转换器才行。 4> Struts2提供支持多种表现层技术，如：JSP、freeMarker、Velocity等 5> Struts2的输入校验可以对指定方法进行校验，解决了Struts1长久之痛。

struts2有什么好处？

1.没有了form Bean，视图层通过OGNL语法直接获取Bean值，这个不是一般的方便啊2.官方有支持Spring IOC的默认配置3.自带的拦截器(Interceptor)把一些通用的业务逻辑比如输入校验、类型转换和参数获取等独立出来，Action中更专注具体业务。也可以自己扩展和配置使用拦截器，比如我就通过拦截器实现了登录信息获取、IP限制、权限验证等功能。4.标签库很强大，但不知道和struts1相比如何。struts2有点不爽的是去掉了webwork2里面的日期控件(jscalendar)，改用了一个datetimepicker的标签，那个控件不是一般的烂。5.和webwork2相比，struts2里面action的配置文件结构更合理一些。

请你谈谈对struts2的理解

因为struts2的Action就具备了struts1中ActionForm的功能；ActionForm的功能无非三个：初始化数据；封装数据；验证数据格式；对于struts2，都有相应的解决方式：通过Action实现Preparable接口，实现对数据初始化；Action继承ActionSupport，重写validate()，显示数据的验证，在Action中配置属性以及对应的getter和setter方法，实现数据封装。而且类型转换方面，struts2通过OGNL实现的效果要比ActionForm更灵活。

struts2 工作原理，为什么用，优缺点

struts框架具有组件的模块化，灵活性和重用性的优点，同时简化了基于MVC的web应用程序的开发。 优点： Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的了解其内部实现机制。 除此之外，Struts的优点主要集中体现在两个方面：Taglib和页面导航。Taglib是Struts的标记库，灵活动用，能大大提高开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。 关于页面导航，我认为那将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。 另外，struts是业界"标准"（很多成功案例），学习资源丰富，HTML标签非常优秀 缺点： Taglib是Struts的一大优势，但对于初学者而言，却需要一个持续学习的过程，甚至还会打乱你网页编写的习惯，但是，当你习惯了它时，你会觉得它真的很棒。 Struts将MVC的Controller一分为三，在获得结构更加清晰的同时，也增加了系统的复杂度。 ActionForms使用不便、无法进行单元测试（StrutsTestCase只能用于集成）    Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的了解其内部实现机制。 Struts开放源码框架的创建是为了使开发者在构建基于Java Servlet和JavaServer Pages（JSP）技术的Web应用时更加容易。Struts框架为开放者提供了一个统一的标准框架，通过使用Struts作为基础，开发者能够更专注于应用程序的商业逻辑。Struts框架本身是使用Java Servlet和JavaServer Pages技术的一种Model-View-Controller（MVC）实现. 具体来讲, Struts的优点有:     1. 实现MVC模式，结构清晰,使开发者只关注业务逻辑的实现.     2. 有丰富的tag可以用 ,Struts的标记库(Taglib)，如能灵活动用，则能大大提高开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。     3. 页面导航.页面导航将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。     4. 提供Exception处理机制 .     5. 数据库链接池管理     6. 支持I18N     缺点:     一、 转到展示层时，需要配置forward，每一次转到展示层，相信大多数都是直接转到jsp，而涉及到转向，需要配置forward，如果有十个展示层的jsp，需要配置十次struts，而且还不包括有时候目录、文件变更，需要重新修改forward，注意，每次修改配置之后，要求重新部署整个项目，而tomcate这样的服务器，还必须重新启动服务器，如果业务变更复杂频繁的系统，这样的操作简单不可想象。现在就是这样，几十上百个人同时在线使用我们的系统，大家可以想象一下，我的烦恼有多大。     二、 Struts 的Action必需是thread－safe方式，它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必需统一同步，这个就引起了线程安全的问题。     三、 测试不方便. Struts的每个Action都同Web层耦合在一起，这样它的测试依赖于Web容器，单元测试也很难实现。不过有一个Junit的扩展工具Struts TestCase可以实现它的单元测试。     四、 类型的转换. Struts的FormBean把所有的数据都作为String类型，它可以使用工具Commons-Beanutils进行类型转化。但它的转化都是在Class级别，而且转化的类型是不可配置的。类型转化时的错误信息返回给用户也是非常困难的。     五、 对Servlet的依赖性过强. Struts处理Action时必需要依赖ServletRequest 和ServletResponse，所有它摆脱不了Servlet容器。     六、 前端表达式语言方面.Struts集成了JSTL，所以它主要使用JSTL的表达式语言来获取数据。可是JSTL的表达式语言在Collection和索引属性方面处理显得很弱。     七、 对Action执行的控制困难. Struts创建一个Action，如果想控制它的执行顺序将会非常困难。甚至你要重新去写Servlet来实现你的这个功能需求。     八、 对Action 执行前和后的处理. Struts处理Action的时候是基于class的hierarchies，很难在action处理前和后进行操作。     九、 对事件支持不够. 在struts中，实际是一个表单Form对应一个Action类(或DispatchAction)，换一句话说：在Struts中实际是一个表单只能对应一个事件，struts这种事件方式称为application event，application ponent event相比是一种粗粒度的事件。         Struts重要的表单对象ActionForm是一种对象，它代表了一种应用，这个对象中至少包含几个字段，这些字段是Jsp页面表单中的input字段，因为一个表单对应一个事件，所以，当我们需要将事件粒度细化到表单中这些字段时，也就是说，一个字段对应一个事件时，单纯使用Struts就不太可能，当然通过结合JavaScript也是可以转弯实现的。 2．Hibernate Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序实用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化的重任。 大多数开发机构经常采取创建各自独立的数据持久层。一旦底层的数据结构发生改变，那么修改应用的其余部分使之适应这种改变的代价将是十分巨大的。Hibernate适时的填补了这一空白，它为Java应用提供了一个易用的、高效率的对象关系映射框架。hibernate是个轻量级的持久性框架，功能却非常丰富。 优点： a.Hibernate 使用 Java 反射机制 而不是字节码增强程序来实现透明性。 b.Hibernate 的性能非常好，因为它是个轻量级框架。 映射的灵活性很出色。 c.它支持各种关系数据库，从一对一到多对多的各种复杂关系。 缺点：它限制您所使用的对象模型。(例如，一个持久性类不能映射到多个表)其独有的界面和可怜的市场份额也让人不安，尽管如此，Hibernate 还是以其强大的发展动力减轻了这些风险。其他的开源持久性框架也有一些，不过都没有 Hibernate 这样有市场冲击力。 上面回贴情绪有点激动，希望谅解，我不是因为有人批评Hibernate而感到不快，而是因为帖子里面的观点实在让我觉得荒谬。不管觉得Hibernate好也吧，不好也吧，我唯一觉得遗憾的是，在中文论坛里面找不到一个对Hibernate的真正高水平的评价。在TSS上有一个关于Hibernate的hot thread，跟了几百贴，其中包括Hibernate作者Gavin和LiDO JDO的CTO，对于JDO和Hibernate有过一些激烈的争论，我曾经耐心的看了一遍，仍然没有发现针对Hibernate真正有力的攻击，那些所谓的攻击无非针对Hibernate没有一个GUI的配置工具，没有商业公司支持，没有标准化等等这些站不住脚的理由。 补充几点我的意见： 一、Hibernate是JDBC的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合，例如Java应用程序的数据库访问代码，DAO接口的实现类，甚至可以是BMP里面的访问数据库的代码。从这个意义上来说，Hibernate和EB不是一个范畴的东西，也不存在非此即彼的关系。 二、Hibernate是一个和JDBC密切关联的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有一定的关系，但是和使用它的Java程序，和App Server没有任何关系，也不存在兼容性问题。 三、Hibernate不能用来直接和Entity Bean做对比，只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的替代者出现的，而不是Entity Bean的替代者出现的，让我再列一次我已经列n次的框架结构： 传统的架构： 1) Session Bean <-> Entity Bean <-> DB 为了解决性能障碍的替代架构： 2) Session Bean <-> DAO <-> JDBC <-> DB 使用Hibernate来提高上面架构的开发效率的架构： 3) Session Bean <-> DAO <-> Hibernate <-> DB 就上面3个架构来分析： 1、内存消耗：采用JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。 2、运行效率：如果JDBC的代码写的非常优化，那么JDBC架构运行效率最高，但是实际项目中，这一点几乎做不到，这需要程序员非常精通JDBC，运用Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。EB的架构效率会差的很远。 3、开发效率：在有JBuilder的支持下以及简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EB架构很可能会失败。 4、分布式，安全检查，集群，负载均衡的支持 由于有SB做为Facade，3个架构没有区别。 四、EB和Hibernate学习难度在哪里？ EB的难度在哪里？不在复杂的XML配置文件上，而在于EB运用稍微不慎，就有严重的性能障碍。所以难在你需要学习很多EJB设计模式来避开性能问题，需要学习App Server和EB的配置来优化EB的运行效率。做EB的开发工作，程序员的大部分精力都被放到了EB的性能问题上了，反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。 Hibernate难在哪里？不在Hibernate本身的复杂，实际上Hibernate非常的简单，难在Hibernate太灵活了。 当你用EB来实现持久层的时候，你会发现EB实在是太笨拙了，笨拙到你根本没有什么可以选择的余地，所以你根本就不用花费精力去设计方案，去平衡方案的好坏，去费脑筋考虑选择哪个方案，因为只有唯一的方案摆在你面前，你只能这么做，没得选择。 Hibernate相反，它太灵活了，相同的问题，你至少可以设计出十几种方案来解决，所以特别的犯难，究竟用这个，还是用那个呢？这些方案之间到底有什么区别呢？他们的运行原理有什么不同？运行效率哪个比较好？光是主键生成，就有七八种方案供你选择，你为难不为难？集合属性可以用Set，可以用List，还可以用Bag，到底哪个效率高，你为难不为难？查询可以用iterator，可以用list，哪个好，有什么区别？你为难不为难？复合主键你可以直接在hbm里面配置，也可以自定义CustomerType，哪种比较好些？你为难不为难？对于一个表，你可以选择单一映射一个对象，也可以映射成父子对象，还可以映射成两个1:1的对象，在什么情况下用哪种方案比较好，你为难不为难？ 这个列表可以一直开列下去，直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候，你会觉得幸福呢？还是悲哀呢？如果你是一个负责的程序员，那么你一定会仔细研究每种方案的区别，每种方案的效率，每种方案的适用场合，你会觉得你已经陷入进去拔不出来了。如果是用EB，你第一秒种就已经做出了决定，根本没得选择，比如说集合属性，你只能用Collection，如果是Hibernate，你会在Bag，List和Set之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。 3． Spring 它是一个开源的项目，而且目前非常活跃；它基于IoC（Inversion of Control，反向控制）和AOP的构架多层j2ee系统的框架，但它不强迫你必须在每一层 中必须使用Spring，因为它模块化的很好，允许你根据自己的需要选择使用它的某一个模块；它实现了很优雅的MVC，对不同的数据访问技术提供了统一的 接口，采用IoC使得可以很容易的实现bean的装配，提供了简洁的AOP并据此实现Transcation Managment，等等 优点： a. Spring能有效地组织你的中间层对象，不管你是否选择使用了EJB。如果你仅仅使用了Struts或其他为J2EE的 API特制的framework，Spring致力于解决剩下的问题。 b. Spring能消除在许多工程中常见的对Singleton的过多使用。根据我的经验，这是一个很大的问题，它降低了系统的可测试性和面向对象的程度。 c. 通过一种在不同应用程序和项目间一致的方法来处理配置文件，Spring能消除各种各样自定义格式的属性文件的需要。曾经对某个类要寻找的是哪个魔法般的属性项或系统属性感到不解，为此不得不去读Javadoc甚至源编码？有了Spring，你仅仅需要看看类的JavaBean属性。Inversion of Control的使用（在下面讨论）帮助完成了这种简化。 d.通过把对接口编程而不是对类编程的代价几乎减少到没有，Spring能够促进养成好的编程习惯。 e. Spring被设计为让使用它创建的应用尽可能少的依赖于他的APIs。在Spring应用中的大多数业务对象没有依赖于Spring。 f. 使用Spring构建的应用程序易于单元测试。 g. Spring能使EJB的使用成为一个实现选择,而不是应用架构的必然选择。你能选择用POJOs或local EJBs来实现业务接口，却不会影响调用代码。 h. Spring帮助你解决许多问题而无需使用EJB。Spring能提供一种EJB的替换物，它们适用于许多web应用。例如，Spring能使用AOP提供声明性事务管理而不通过EJB容器，如果你仅仅需要与单个数据库打交道，甚至不需要一个JTA实现。 i. Spring为数据存取提供了一个一致的框架,不论是使用的是JDBC还是O/R mapping产品（如Hibernate）。 Spring确实使你能通过最简单可行的解决办法来解决你的问题。而这是有有很大价值的。 缺点：使用人数不多、jsp中要写很多代码、控制器过于灵活，缺少一个公用控制器

struts1和struts2的最大的差别在哪，struts2的突出成就是什么

Struts2虽然在大版本号上是第二个版本，但基本上在配置和使用上已经完全颠覆了 Struts1.x的方式（当然，Struts2仍然是基于MVC模式的，也是动作驱动的，可能这是唯一 没变的东西）。Struts2实际上是在Webwork基础上构建起来的MVC 框架。我们从Struts2的 源代码中可以看到，有很多都是直接使用的xwork(Webwork的核心技术)的包。 Struts2和Struts1的不同 Action 类 ?Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口。 ?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 使用ActionForm对象捕获输入。所有的ActionForm必须继承一个基类。因为其他JavaBean不能用作ActionForm，开发者经常创建多余的类捕获输入。动态Bean（DynaBeans）可以作为创建传统ActionForm的选择，但是，开发者可能是在重新描述(创建)已经存在的JavaBean（仍然会导致有冗余的javabean）。 ?Struts 2直接使用Action属性作为输入属性，消除了对第二个输入对象的需求。输入属性可能是有自己(子)属性的rich对象类型。Action属性能够通过web页面上的taglibs访问。Struts2也支持ActionForm模式。rich对象类型，包括业务对象，能够用作输入/输出对象。这种ModelDriven 特性简化了taglib对POJO输入对象的引用。 可测性 ?测试Struts1 Action的一个主要问题是execute方法暴露了servlet API（这使得测试要依赖于容器）。一个第三方扩展－－Struts TestCase－－提供了一套Struts1的模拟对象（来进行测试）。 ?Struts 2 Action可以通过初始化、设置属性、调用方法来测试，“依赖注入”支持也使测试更容易。 表达式语言 ?Struts1 整合了JSTL，因此使用JSTL EL。这种EL有基本对象图遍历，但是对集合和索引属性的支持很弱。 ?Struts2可以使用JSTL，但是也支持一个更强大和灵活的表达式语言－－"Object-Graph Navigation 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一起使用。

求Struts2的详细原理

第一步：当用户发出请求，这些请求首先通过Struts中的一系列过滤器，如Struts自带的ActionContextCleanUp过滤器，它主要负责清理单前线程，防止内存泄露，充当清洁工的作用。还可以是你自己自定义的过滤器，这些自定义的过滤器要在web.xml里配置，最后就通过Struts2核心过滤器FilterDispatcher，也叫核心中央控制器，主要是拦截用户的HTTP情求，然后根据配置文件struts.xml的具体调用指定的业务控制器Action，第二步：经过Struts2中的核心过滤器中有个内部组件Action映射器。第三步：这个Action映射器会根据Struts配置文件(struts.xml struts.properties)，由Struts2配置管理器读取Struts2生成个Action代理(这里用了个面向切面思想AOP，切面就是横切面，代表是一个普遍存在的共有功能)第四步：生成的这个代理因为是用了AOP思想就可以经过一系列的拦截器，这就进入了Action执行环境了.第五步：开始经过的一系列预处理拦截器是进行进入Action执行环境预处理，这些拦截器是系统自带的也可以自己自定义的。第六步：执行了预处理拦截器后就会进入Struts2配置文件目标目标控制器Action类。第七步：通过调用Action类得方法将返回一个Result命名视图(是物理视图的一个别名而已，在配置文件中每两个两个视图都对应配置好的）第八步：这些视图可能是 HTML，Jsp页面，FreeMarker模板等第九步：这些视图可能会用到Struts2标签库第九步：通过这些标签库解析把结果返回到视图中第九步：处理好的视图在返回给用户之前还要在经过一系列后处理拦截器，最后第十步：才把最终的结果返回给用户。

struts2的基本结构和构成

您好：Struts是一个在JSPModel2基础上实现的MVC框架，主要分为模型(Model)、视图(Viewer)和控制器(Controller)三部分，其主要的设计理念是通过控制器将表现逻辑和业务逻辑解耦，以提高系统的可维护性、可扩展性和可重用性。 （1）视图：视图部分主要由JSP页面组成，其中没有流程逻辑、业务逻辑和模型信息，只有标记。Struts自身包含了一组标记库(TagLib)，这也是Struts的精华之一，灵活运用它们可以简化JSP页面的代码，提高开发效率。 （2）控制器：Struts中的Controller主要是其自身提供的ActionServlet。ActionServlet接收所有来自客户端的请求并根据配置文件(struts-config.xml)中的定义将控制转移到适当的Action对象。 （3）模型：Struts没有定义具体Model层的实现，Model层通常是和业务逻辑紧密相关的，有持续化的要求。目前在商业领域和开源世界，都有一些优秀的工具可以为Model层的开发提供便利。

Struts2的流程是什么？

Struts内部流程： 当接收到一个httprequest Interceptor做一些拦截或者初始的工作 当外部的httpservletrequest到来时 初始到了servlet容器 传递给一个标准的过滤器链 ActionContextCleanUp这个在集成插件方面非常有用 Other filters(SitMesh,etc) 调用FilterDispatecher会去查找相应的ActionMapper 如果找到了相应的ActionMapper它将会将控制权限交给ActionProxy ActionProxy将会通过ConfigurationManager来查找配置struts.xml 下一步将会 通过ActionInvocation来负责命令模式的实现（包括调用一些拦截Interceptor框架在调用action之前） 一旦action返回，会查找相应的Result Result类型可以是 jsp或者freeMark 等 这些组件和ActionMapper一起返回给请求的url（注意拦截器的执行顺序） 响应的返回是通过我们在web.xml中配置的过滤器 如果ActionContextCleanUp是当前使用的，则FilterDispatecher将不会清理 sreadlocal ActionContext 如果ActionContextCleanUp不使用，则将会去清理sreadlocals

Struts2的核心工作原理

.Struts 2的基本流程 Struts 2框架由3个部分组成：核心控制器FilterDispatcher、业务控制器和用户实现的业务逻辑组件。在这3个部分里，Struts 2框架提供了核心控制器FilterDispatcher，而用户需要实现业务控制器和业务逻辑组件。 2.核心控制器：FilterDispatcher FilterDispatcher是Struts 2框架的核心控制器，该控制器作为一个Filter运行在Web应用中，它负责拦截所有的用户请求，当用户请求到达时，该Filter会过滤用户请求。如果用户请求以action结尾，该请求将被转入Struts 2框架处理。 Struts 2框架获得了*.action请求后，将根据*.action请求的前面部分决定调用哪个业务逻辑组件，例如，对于login.action请求，Struts 2调用名为login的Action来处理该请求。 Struts 2应用中的Action都被定义在struts.xml文件中，在该文件中定义Action时，定义了该Action的name属性和class属性，其中name属性决定了该Action处理哪个用户请求，而class属性决定了该Action的实现类。 Struts 2用于处理用户请求的Action实例，并不是用户实现的业务控制器，而是Action代理——因为用户实现的业务控制器并没有与Servlet API耦合，显然无法处理用户请求。而Struts 2框架提供了系列拦截器，该系列拦截器负责将HttpServletRequest请求中的请求参数解析出来，传入到Action中，并回调Action 的execute方法来处理用户请求。 显然，上面的处理过程是典型的AOP（面向切面编程）处理方式。图3.19显示了这种处理模型。 图3.19 Struts 2的拦截器和Action 从图3.19中可以看出，用户实现的Action类仅仅是Struts 2的Action代理的代理目标。用户实现的业务控制器（Action）则包含了对用户请求的处理。用户的请求数据包含在 HttpServletRequest对象里，而用户的Action类无需访问HttpServletRequest对象。拦截器负责将 HttpServletRequest里的请求数据解析出来，并传给业务逻辑组件Action实例。 3.业务控制器 正如从图3.19所看到的，业务控制器组件就是用户实现Action类的实例，Action类里通常包含了一个execute方法，该方法返回一个字符串——该字符串就是一个逻辑视图名，当业务控制器处理完用户请求后，根据处理结果不同，execute方法返回不同字符串 ——每个字符串对应一个视图名。 我觉得，问题应该是考察是否对系统架构设计有一定的了解，能否清楚的运用自己的理解表述软件设计中的相互沟通要点。

struts和struts2的区别

struts1和struts2 是2个完全不同的框架，其实struts2核心就是 webwork框架 struts1以ActionServlet作为核心控制器，由ActionServlet负责拦截用户的所有请求。Struts 1框架有3个重要组成部分：Action、ActionForm和ActionForward对象。ActionForm必须实现ActionForm的基类,设计上并不是真正的POJO。 struts2核心控制器是FilterDispatcher，Struts 2用于处理用户请求的Action实例，并不是用户实现的业务控制器，而是Action代理——因为用户实现的业务控制器并没有与Servlet API耦合，显然无法处理用户请求。而Struts 2框架提供了系列拦截器，该系列拦截器负责将HttpServletRequest请求中的请求参数解析出来，传入到Action中，并回调Action的execute方法来处理用户请求。显然，上面的处理过程是典型的AOP（面向切面编程）处理方式。

struts2的主要的具体工作流程

struts2的主要工作流程是这样的： 首先有一个http请求，会首先进入ActionContextCleanup（清空值栈等，但会留下自己的，比如session，Attribute等），其作用见括号中的 其次，走一些过滤器，filter，然后进入闻名的struts2的总控FilterDispatcher 穿过上述几层后，会进入ActionMapper，来判断此请求是否需要struts2处理，如果需要，那么由ActionProxy来接管，通过配置管理我们可以找到我们的struts.xml,然后进入真正做事的Action Invocation，依次穿过我们的拦截器，进入action，从而根据返回的result选择我们要的页面，在拦截器的前半部分去值栈中取值通过标签展示在页面上，最后生成response返回，具体的图如下 此图是我自己总结的，颜色比较多的那个图是struts2的官方图片，只是加了注释 struts2说的应用一些，举例，就像我们图中的，当你点击新增按钮后，会触发一个action给web服务器，服务器接受请求，给对应的web容器，根据上下文可以找到我们的webapp应用，找到总的配置文件web.xml，根据里面的配置来判断action谁去处理，找到filter，反射创建类，回调init，读取struts2的配置文件struts.xml，根据命名空间等找到action，反射创建action类实例，回到execute方法，找到对应的result转向下一个页面，其中虚线框中为右图的一个简写

为什么要用到struts2

展开全部 Apache Struts在2000年5月由 Craig McClanahan 发起，并于2001年7月发布了1.0版本。从技术的角度上讲，它是在开发Web程序上的一次跨越性的进步，但更重要的是，它是在最恰当的时候出现在了人们的眼前。Struts 一出现便大受欢迎，更成为了以后几年内web开发的实际标准。 Struts2是Struts的下一代产品。最初提案Struts Ti所设想的发展方向，在Struts的现有代码的基础上是很难完成的。在发起提案的时候，Patrick Lightbody 把多个不同的Web框架的领导者邀请到了一起，希望大家能够协力完成一个通用的框架。但因种种原因，只有WebWork和Struts走到了一起。Struts2吸取了Struts1.x和WebWork的各种优点，更改了一些不足的地方，比如移走了原来WebWork中的IOC实现，引入Spring的IOC实现等。Struts2的目标就是----使Web开发更加容易。 今天摆在web开发人员面前的是众多的web开发框架，有些来自开源社区，有些来自商业公司，以满足各种web开发需要，到目前为止，有最少超过40种的web开发框架，那我们为什么要选择Struts2呢？下面列出一些Struts2的特性。 基于pojo易于测试 在Struts1.x中我需要Mock出这两个Http对象，使我们很难编写Action的单元测试，与Struts1.x相比，Struts2的Action 不再依赖于HttpServletRequest和HttpServletResponse对象，使我们能够更方便的针对Action编写单元测试。Struts2的单元测试看起来就像这样： public void testEnrol(){ userinfoAction.setUsername("wangwu"); userinfoAction.setUserPassword("123456"); userinfoAction.setMail(""); String result = userinfoAction.enrol(); assertEquals("ess",result); } 与Spring的集成 与Struts1.x相比，Struts2不必再自己编写singleton，进一步的降低了程序间的耦合性，就Struts2内部本身而言，降低了框架本身的偶合性。 更加的模块化 与Struts1.X 相比，Struts2更加的模块化，可以轻松将配置信息按功能界限拆分成多个文件，便于管理和团队协作开发。 基于插件的框架 Struts2是一个基于插件的框架，社区中提供了很多实用的插件，比如jfreechat/json等等，使用这些插件可以简化我们的开发，加快开发进度。 大量的拦截器 Struts2本身提供了大量的可重用的拦截器，比如类型转换拦截器，很多时候我们从页面取得参数，这个时候它是String类型的，我们需要手动的把它转成Long型的或是Integer型的再使用，在Struts2中你不必这样做，Struts2中已经帮你做了这些事情了。当然我们也可以实现自定义的拦截器，比如：权限检查拦截器来做访问控制。 惯例大于配置 惯例大于配置是Struts2的架构目标，比如我们需要对页面输入的数据进行验证，只需取一个跟Action同名的xxAction-validation.xml文件，Struts2就会自动的进行验证。还有很多，比如国际化资源文件等。 多种视图的支持 多种视图的支持：jsp，freemarker，Veloctiy，只要你愿意，你甚至可以通过轻松的改造让它支持pdf，同一个项目中你可以支持多种视图。 申明式的异常处理 Struts2提供了方便的申明式异常处理，它看起来像这样： /WEB-INF/pages/client/licenceException.jsp /WEB-INF/pages/client/unPay.jsp /WEB-INF/pages/client/essDeny.jsp 如果你以前是WebWork的用户，那么你会觉得Struts2和WebWork实在是太像了，当然如果你以前是Struts1.x的忠实用户，也能够快速的过渡到Struts2的开发中来，如果你重来没有用过任何框架，你也可以通过快速的学习，加入到Struts2的应用开发中来，因为它足够的简单。

struts2是工作原理

<p>struts2并不是一个陌生的web框架，它是以Webwork的设计思想为核心，吸收struts1的优点，可以说</p> <p>struts2是struts1和Webwork结合的产物。?</p> <p>struts2?的工作原理图：</p> <p>一个请求在Struts2框架中的处理分为以下几个步骤：</p> <p>1.客户端发出一个指向servlet容器的请求(tomcat)；</p> <p>2.这个请求会经过图中的几个过滤器，最后会到达FilterDispatcher过滤器。</p> <p>3.过滤器FilterDispatcher是struts2框架的心脏，在处理用户请求时，它和请求一起相互配合访问struts2的底层框架结构。在web容器启动时，struts2框架会自动加载配置文件里相关参数，并转换成相应的类。??如：ConfigurationManager、ActionMapper和ObjectFactory。ConfigurationManager?存有配置文件的一些基本信息，ActionMapper存有action的配置信息。在请求过程中所有的对象（Action，Results,Interceptors，等）都是通过ObjectFactory来创建的。过滤器会通过询问ActionMapper类来查找请求中需要用到的Action。</p> <p>4.如果找到需要调用的Action，过滤器会把请求的处理交给ActionProxy。ActionProxy为Action的代理对象??。ActionProxy通过ConfigurationManager询问框架的配置文件，找到需要调用的Action类。</p> <p>5.ActionProxy创建一个ActionInvocation的实例。ActionInvocation在ActionProxy层之下，它表示了??Action的执行状态,或者说它控制的Action的执行步骤。它持有Action实例和所有的Interceptor。?</p> <p>6.ActionInvocation实例使用命名模式来调用，1.?ActionInvocation初始化时，根据配置，加载Action相??关的所有Interceptor。2.?通过ActionInvocation.invoke方法调用Action实现时，执行Interceptor。在??调用Action的过程前后，涉及到相关拦截器(intercepetor)的调用。</p> <p>7.?一旦Action执行完毕，ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。返回结果??通常是（但不总是，也可能是另外的一个Action链）一个需要被表示的JSP或者FreeMarker的模版。在表??示的过程中可以使用Struts2?框架中继承的标签。</p> <p></p> <p>?</p> <p>?</p>

struts2与struts的区别

1.struts1的action是单例模式且必须是线程安全的,action的一个实例处理所有请求. struts2的action对象为每个请求产生一个实例,没有线程安全问题. struts1的action依赖于servlet api,struts2的action不依赖与容器,允许脱离容器单独测试. 2.struts1的execute方法依赖于servlet api,使得测试要依赖于容器.struts2的action可以通过初始化,设置属性,调用方法来测试,依赖注入支持是测试更容易. struts1试用ActionForm对象捕获输入,普通JavaBean不能捕获输入.动态bean可以作为ActionForm的选择,但是是在重复描述已经存在的Javabean. struts2直接试用action属性作为输入属性,消除了对第二个输入对象的需求.也支持ActionForm模式,这种ModelDriven特性简化了tiglib对POJO对象的应用. 3.struts1整合的JSTL,试用JSTL EL,EL有基本对象图遍历功能,但是对集合和索引属性的支持很弱 struts2可以使用JSTL,但是也支持一个更强大和灵活的表达式语言-- Object Graph Notation Language(OGNL) 4.struts1试用标准jsp机制把对象绑定到页面中来访问 struts2试用ValueStack技术,允许试用一系列名称相同但类型不同的属性重用页面 5.struts1的ActionForm通常都是String类型,试用BeanUtils进行类型转换 struts2使用OGNL进行类型转换,提供基本和常用对象的转化器. 6.struts1支持在ActionForm的validate方法中手动效验,或者通过validator扩展效验 struts2支持通过validate方法和XWork效验框架来进行效验 7.struts1支持每个模块有单独的request生命周期,但是模块中的所有action必须共享相同的生命周期 struts2支持通过拦截器interceptor stacks为每个action创建不同的生命周期