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

struts1的工作原理图:

struts1与struts2的差别_开发人员

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工作原理

struts1与struts2的差别_web容器_02


一个请求在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。从而 减少了代码污染。