struts1与struts2的差别



Struts 2是Struts的下一代产品，是在 struts 1和WebWork的技术基础上进行了合并的全新的Struts 2框架。其全新的Struts 2的体系结构与Struts 1的体系结构区别巨大。Struts 2以WebWork为核心，採用拦截器的机制来处理用户的请求，这种设计也使得业务逻辑控制器可以与ServletAPI全然脱离开。所以Struts 2可以理解为WebWork的更新产品。

struts1的工作原理图：

wx_fmt=jpeg&wxfrom=5&wx_lazy=1" alt="" style="margin:0px auto; width:auto!important; height:auto!important; text-align:center; display:block; visibility:visible!important">

1.初始化：struts框架的总控制器ActionServlet是一个Servlet。它在web.xml中配置成自己主动启动的Servlet，在启动时总控制器会读取配置文件(struts-config.xml)的配置信息。为struts中不同的模块初始化对应的对象。(面向对象思想)

2.发送请求：用户提交表单或通过URL向WEBserver提交请求。请求的数据用HTTP协议传给webserver。

3.form填充：struts的总控制器ActionServlet在用户提交请求时将数据放到相应的form对象中的成员 变量中。

4.派发请求：控制器依据配置信息对象ActionConfig将请求派发到详细的Action，相应的formBean一并传给这个Action中的excute()方法。

5.处理业务：Action一般仅仅包括一个excute()方法。它负责运行对应的业务逻辑(调用其他的业务模块)完成后返回一个ActionForward对象。server通过ActionForward对象进行转发工作。

6.返回响应：Action将业务处理的不同结果返回一个目标响应对象给总控制器。

7.查找响应：总控制器依据Action处理业务返回的目标响应对象，找到相应的资源对象。普通情况下为jsp页面。

8.响应用户：目标响应对象将结果传递给资源对象，将结果展现给用户。

Struts2工作原理

一个请求在Struts2框架中的处理大概分为下面几个步骤

1、client初始化一个指向Servlet容器（比如Tomcat）的请求

2、这个请求经过一系列的过滤器（Filter）（这些过滤器中有一个叫做ActionContextCleanUp的可选过滤器。这个过滤器对于Struts2和其它框架的集成非常有帮助，比如：SiteMesh
Plugin）

3、接着FilterDispatcher被调用，FilterDispatcher询问ActionMapper来决定这个请是否须要调用某个Action
FilterDispatcher是控制器的核心，就是mvc中c控制层的核心。以下粗略的分析下我理解的FilterDispatcher工作流程和原理：FilterDispatcher进行初始化并启用核心doFilter。

4、假设ActionMapper决定须要调用某个Action，FilterDispatcher把请求的处理交给ActionProxy

5、ActionProxy通过ConfigurationManager询问框架的配置文件，找到须要调用的Action类
,这里。我们通常是从struts.xml配置中读取。

6、ActionProxy创建一个ActionInvocation的实例。

7、ActionInvocation实例使用命名模式来调用。在调用Action的过程前后，涉及到相关拦截器（Intercepter）的调用。

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。从而 减少了代码污染。