struts1和struts2对比

转载 2011年01月14日 11:50:00

现在总会有人拿struts1和struts2来做比较,这里做一些简单的收集总结。
一.MVC的特点:
— 多个视图可以对应一个模型。按MVC设计模式,一个模型对应多个视图,可以减少代码的复制及代码的维护量,一旦模型发生改变,也易于维护。
— 模型返回的数据与显示逻辑分离。模型数据可以应用任何的显示技术,例如,使用JSP页面、Velocity模板或者直接产生Excel文档等。
— 应用被分隔为三层,降低了各层之间的耦合,提供了应用的可扩展性。
— 控制层的概念也很有效,由于它把不同的模型和不同的视图组合在一起,完成不同的请求。因此,控制层可以说是包含了用户请求权限的概念。
—  MVC更符合软件工程化管理的精神。不同的层各司其职,每一层的组件具有相同的特征,有利于通过工程化和工具化产生管理程序代码。



二.Struts1的特点
Struts 1以ActionServlet作为核心控制器,由ActionServlet负责拦截用户的所有请求。Struts 1框架有3个重要组成部分:Action、ActionForm和ActionForward对象。
ActionForm必须实现ActionForm的基类,设计上并不是真正的POJO
ActionForward就是一个逻辑视图,通过在配置文件中定义ActionFoward的映射,完成逻辑视图名和实际视图资源之间的映射
Struts 1的Action类与Struts 2的Action类有一定的类似性,都通过调用execute方法来处理用户请求。但最大的区别在于Struts 1 Action的execute方法与Servlet API耦合(ActionServlet继承自HttpServlet),但Struts 2 Action类的execute方法无需与Servlet API耦合。

struts1的缺陷:
(1).只支持JSP作为表现层技术,不能与Velocity,FreeMarker等技术整合
(2).与Servlet API严重耦合,难于测试
一个exute有四个参数ActionMapping、ActionForm、HttpServletRequest和HttpServletResponse,初始化困难.
(3).侵入式设计,严重依赖于Struts1API,如如ActionMapping、ActionForm和ActionForward类.一旦系统需要重构时,这些类完全没有利用价值,导致较低的代码复用.



三.Struts2的特点
struts2核心控制器:FilterDispatcher
Struts 2用于处理用户请求的Action实例,并不是用户实现的业务控制器,而是Action代理——因为用户实现的业务控制器并没有与Servlet API耦合,显然无法处理用户请求。而Struts 2框架提供了系列拦截器,该系列拦截器负责将HttpServletRequest请求中的请求参数解析出来,传入到Action中,并回调Action的execute方法来处理用户请求。显然,上面的处理过程是典型的AOP(面向切面编程)处理方式。



Struts2 Action有以下特点:
—  Action类完全是一个POJO,因此具有很好的代码复用性。
—  Action类无需与Servlet API耦合,因此进行单元测试非常简单。
—  Action类的execute方法仅返回一个字符串作为处理结果,该处理结果可映射到任何的视图,甚至是另一个Action。

Struts 2的配置文件有两份:
—配置Action的struts.xml文件。
—配置Struts 2全局属性的struts.properties文件。

下面是struts.xml配置文件的示例:

Xml代码
<struts>  
        <!-- Struts 2的Action都必须配置在package里 -->  
  <package name="default" extends="struts-default">  
         <!-- 定义一个Logon的Action,实现类为lee.Logon -->  
    <action name="Logon" class="lee.Logon">  
        <!-- 配置Action返回input时转入/pages/Logon.jsp页面 -->  
      <result name="input">/pages/Logon.jsp</result>  
        <!-- 配置Action返回cancel时重定向到Welcome的Action-->  
      <result name="cancel" type="redirect-action">Welcome</result>  
        <!-- 配置Action返回success时重定向到MainMenu的Action -->  
      <result type="redirect-action">MainMenu</result>  
        <!-- 配置Action返回expired时进入ChangePassword的Action链 -->  
      <result name="expired" type="chain">ChangePassword</result>  
    </action>  
        <!-- 定义Logoff的Action,实现类为lee.Logoff -->  
    <action name="Logoff" class=" lee.Logoff">  
        <!-- 配置Action返回success时重定向到MainMenu的Action -->  
      <result type="redirect-action">Welcome</result>  
    </action>  
  </package>  
</struts> 
<struts>
        <!-- Struts 2的Action都必须配置在package里 -->
  <package name="default" extends="struts-default">
         <!-- 定义一个Logon的Action,实现类为lee.Logon -->
    <action name="Logon" class="lee.Logon">
        <!-- 配置Action返回input时转入/pages/Logon.jsp页面 -->
      <result name="input">/pages/Logon.jsp</result>
        <!-- 配置Action返回cancel时重定向到Welcome的Action-->
      <result name="cancel" type="redirect-action">Welcome</result>
        <!-- 配置Action返回success时重定向到MainMenu的Action -->
      <result type="redirect-action">MainMenu</result>
        <!-- 配置Action返回expired时进入ChangePassword的Action链 -->
      <result name="expired" type="chain">ChangePassword</result>
    </action>
        <!-- 定义Logoff的Action,实现类为lee.Logoff -->
    <action name="Logoff" class=" lee.Logoff">
        <!-- 配置Action返回success时重定向到MainMenu的Action -->
      <result type="redirect-action">Welcome</result>
    </action>
  </package>
</struts>

四.Struts1与Struts2的比较:
— 在Action实现类方面的对比:Struts 1要求Action类继承一个抽象基类;Struts 1的一个具体问题是使用抽象类编程而不是接口。Struts 2 Action类可以实现一个Action接口,也可以实现其他接口,使可选和定制的服务成为可能。Struts 2提供一个ActionSupport基类去实现常用的接口。即使Action接口不是必须实现的,只有一个包含execute方法的POJO类都可以用作Struts 2的Action。

— 线程模式方面的对比:Struts 1 Action是单例模式并且必须是线程安全的,因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts 1 Action能做的事,并且要在开发时特别小心。Action资源必须是线程安全的或同步的;Struts 2 Action对象为每一个请求产生一个实例,因此没有线程安全问题。

—  Servlet依赖方面的对比:Struts 1 Action依赖于Servlet API,因为Struts 1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。Struts 2 Action不再依赖于Servlet API,从而允许Action脱离Web容器运行,从而降低了测试Action的难度。 当然,如果Action需要直接访问HttpServletRequest和HttpServletResponse参数,Struts 2 Action仍然可以访问它们。但是,大部分时候,Action都无需直接访问HttpServetRequest和HttpServletResponse,从而给开发者更多灵活的选择。

— 可测性方面的对比:测试Struts 1 Action的一个主要问题是execute方法依赖于Servlet API,这使得Action的测试要依赖于Web容器。为了脱离Web容器测试Struts 1的Action,必须借助于第三方扩展:Struts TestCase,该扩展下包含了系列的Mock对象(模拟了HttpServetRequest和HttpServletResponse对象),从而可以脱离Web容器测试Struts 1的Action类。Struts 2 Action可以通过初始化、设置属性、调用方法来测试。

— 封装请求参数的对比:Struts 1使用ActionForm对象封装用户的请求参数,所有的ActionForm必须继承一个基类:ActionForm。普通的JavaBean不能用作ActionForm,因此,开发者必须创建大量的ActionForm类封装用户请求参数。虽然Struts 1提供了动态ActionForm来简化ActionForm的开发,但依然需要在配置文件中定义ActionForm;Struts 2直接使用Action属性来封装用户请求属性,避免了开发者需要大量开发ActionForm类的烦琐,实际上,这些属性还可以是包含子属性的Rich对象类型。如果开发者依然怀念Struts 1 ActionForm的模式,Struts 2提供了ModelDriven模式,可以让开发者使用单独的Model对象来封装用户请求参数,但该Model对象无需继承任何Struts 2基类,是一个POJO,从而降低了代码污染。

— 表达式语言方面的对比:Struts 1整合了JSTL,因此可以使用JSTL表达式语言。这种表达式语言有基本对象图遍历,但在对集合和索引属性的支持上则功能不强;Struts 2可以使用JSTL,但它整合了一种更强大和灵活的表达式语言:OGNL(Object Graph Notation Language),因此,Struts 2下的表达式语言功能更加强大。

— 绑定值到视图的对比:Struts 1使用标准JSP机制把对象绑定到视图页面;Struts 2使用“ValueStack”技术,使标签库能够访问值,而不需要把对象和视图页面绑定在一起。

— 类型转换的对比:Struts 1 ActionForm 属性通常都是String类型。Struts 1使用Commons-Beanutils进行类型转换,每个类一个转换器,转换器是不可配置的;Struts 2使用OGNL进行类型转换,支持基本数据类型和常用对象之间的转换。

— 数据校验的对比:Struts 1支持在ActionForm重写validate方法中手动校验,或者通过整合Commons alidator框架来完成数据校验。Struts 2支持通过重写validate方法进行校验,也支持整合XWork校验框架进行校验。

—  Action执行控制的对比:Struts 1支持每一个模块对应一个请求处理(即生命周期的概念),但是模块中的所有Action必须共享相同的生命周期。Struts 2支持通过拦截器堆栈(Interceptor Stacks)为每一个Action创建不同的生命周期。开发者可以根据需要创建相应堆栈,从而和不同的Action一起使用。

--struts2有许多功能强大的拦截器,struts1没有。

相关文章推荐

Struts1和Struts2的比較

Struts1和Struts2的比較 翻譯:zhiyong.tong 出自:Apache Struts 2 Documentation 特性 Struts 1 ...

Struts1和Struts2的区别

本文将从Struts1和Struts2的各个方面进行比较 本文仅供参考,原文可点击如下地址查看 http://struts.apache.org/2.0.11/docs/comparing...

Struts2讲义,和Struts1

  • 2010-10-24 14:14
  • 3.97MB
  • 下载

struts1和struts2的区别.txt

MVC控制层struts1、struts2、springmvc

MVC是web开发常用的模式,M即模型层(Model):主要由javabean来实现。V即视图层(View):主要由jsp、velocity、freemarker等。C即控制层(Controller)...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)