spring与struts的区别,springmvc和strtus2的区别
spring与struts的区别,springmvc和strtus2的区别详细介绍
本文目录一览： 请问spring与struts有什么区别？
1、实现机制不同
struts2框架是类级别的拦截，每次来了请求就创建一个controller中对应的Action，然后调用setter getter方法把request中的数据注入 。struts2实际上是通过setter getter方法与request打交道的。struts2中，一个Action对象对应一个request上下文。
spring3 mvc不同，spring3mvc是方法级别的拦截，拦截到方法后根据参数上的注解，把request数据注入进去。在spring3mvc中，一个方法对应一个request上下文，而方法同时又跟一个url对应。
spring mvc的入口是servlet，而struts2是filter。spring mvc会稍微比struts快。
2、Request数据共享不同
spring3mvc的方法之间基本上独立的，独享request response数据。请求数据通过参数获取，处理结果通过ModelMap交回给框架，方法之间不共享变量。
struts2就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的。这不会影响程序运行，却给编码、读程序时带来麻烦 。
3、参数传不同
struts是在接受参数的时候，可以用属性来接受参数，这就说明参数是让多个方法共享的。
4、设计思想上不同
struts更加符合oop的编程思想， spring就比较谨慎，在servlet上扩展。
5、intercepter的实现机制不同
struts有以自己的interceptor机制，spring mvc用的是独立的AOP方式。这样导致struts的配置文件量还是比spring mvc大，虽然struts的配置能继承，所以论使用上来讲，spring mvc使用更加简洁，开发效率Spring MVC确实比struts2高。
参考资料：百度百科—struts
参考资料：百度百科—spring
springmvc和struts2的区别
springmvc和struts2的区别是有好多：线程是否安全、机制一个是servlet一个filter、struts2是栈等等，目前互联网公司基本都会用springmvc，struts2用的太少了
1. 机制：
spring mvc的入口是servlet，而struts2是filter，这样就导致了二者的机制不同。
2. 性能：
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上下文。
3. 参数传递：
struts是在接受参数的时候，可以用属性来接受参数，这就说明参数是让多个方法共享的。
4. 设计思想上：
struts更加符合oop(面向对象编程)的编程思想， spring就比较谨慎，在servlet上扩展。
SpringMVC，Spring和Struts的区别
一、Spring
首先，结合到自己对于Spring的使用，我明确的一点是，Spring严格上来说，并不是一种框架。它相当于一个粘合剂，黏合了别的框架或者组件。所以，spring是一个容器！为什么用Spring，个人感觉，spring就是一个容器的本质，程序开发的模块组件，都可以通过spring这个容器进行组装拼合，spring为我们提供了很多 管理的功能。而且，它是一个轻量级的容器。我们常说EJB是重量级，Spring是轻量级的，那么，究竟什么叫轻量级或重量级呢？
附：轻量级和重量级（往简单了说）
首先；轻量级和重量级，它只是一个相对的概念。如果没有对比，就没有所谓的轻重之分
轻量级：当轻量级的框架启动时，创建和销毁的资源都非常少。简而言之，一个轻量级的框架，它的入侵性非常小，也可以说是耦合性很低。可以很轻易的替换掉它，而不需要做太大的改动，它对别的组件的依赖非常小！
重量级：和轻量级相对，引入一个重量级的框架，意味着需要引入相当多的依赖和其他组件，当需要修改这个框架时，基本上面临着重组的危机！
二、SpringMVC
从Spring的结构图可以看出，springMVC位于spring web端的一个框架，是一种基于Java的实现了Web MVC设计模式的请求驱动类型的轻量级Web框架，即使用了MVC架构模式的思想，将web层进行职责解耦。附：基于请求驱动指的就是使用请求-响应模型。从原理上看，它基本上和.NET的MVC的原理相同！
三、Spring和SpringMVC的联系
从名字上就可以窥探出，Spring>SpringMVC，那么事实上，spring和SpringMVC是一种父子关系。SpringMVC是spring扩展出的一个应用于web端的框架。在这里需要注意的一点，就是到底什么是父子容器关系：
spring主要的作用是黏合其他模块组件，进行统一管理，springmvc则主要是负责web端。那么，我们都知道，我们在应用spring的时候，可以使用注入。这个时候，如果我们的web端是用的SpringMVC，这个时候，controller理论上是通过SpringMVC去注入，但是，使用spring注入，同样是可行的。同理，service等层，使用SpringMVC配置的统一扫描装配也是可以的。所以，如果说只是为了使用spring的依赖注入，是大可不必将springMVC和spring同时使用的。他们完全可以分开！
但是，尽管SpringMVC和spring都可以进行自动装配扫描，值得注意的是：
spring（父容器）并不能直接访问SpringMVC（子容器）所注入的对象，但是SpringMVC却可以访问到spring装载的对象。所以，在配置自动装配的时候，应该注意到这一点。
四、Struts
Struts是对于MVC的一种非常完美的实现，从根本上来说，它其实和SpringMVC一样，都是基于MVC思想的扩展实现。但是，在SpringMVC3之后 ，SpringMVC完超Struts。（注：但是，框架并没有优劣之分，框架本身就是一种权衡，相对而言而已）
Struts和SpringMVC的区别：
首先，如果说项目中使用了spring，那么还是使用SpringMVC吧，因为相对于融合Struts来说，spring和SpringMVC是非常完美的无缝链接。
其次，SpringMVC的拦截粒度是方法，而Struts的粒度是类
然后，入口不同，SpringMVC的入口是servlet，而Struts是filter
最后，如果使用注解的话，SpringMVC基本上是零配置，而Struts需要配置很多。
备注：想说一点的是：在Struts中可以配置开发者模式，就是说当修改了一个URL访问，可以不用重启工程。但是SpringMVC需要重启。
springmvc和strtus2的区别
1、springmvc基于方法开发的，struts2基于类开发的。
2、单例和多例的区别：springmvc在映射的时候，通过形参来接收参数的，是将url和controller方法映射，映射成功后，springmvc生成一个handlers对象，对象中只包括一个method，方法执行结束的时候，形参的数据就销毁，
所以springmvc可以进行单例开发，并且建议使用。
但是structs接收的参数是通过类的成员变量来接收的，这些变量在多线程访问中，是共享的，而不是像springmvc那样，方法结束之后，形参自动销毁，且无法使用单例，只能使用多例。
3、structs速度慢，在与使用structs标签，如果使用structs建议使用jstl。
4、机制：spring mvc的入口是servlet，而struts2是filter，这样就导致了二者的机制不同。
5、设计思想上：struts更加符合oop(面向对象编程)的编程思想， spring就比较谨慎，在servlet上扩展。
springmvc和struts2的区别
1:
spring3 mvc开发效率高于struts
2:
spring3 mvc可以认为已经100%零配置
3:
struts2是类级别的拦截， 一个类对应一个request上下文，
springmvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应
所以说从架构本身上 spring3 mvc就容易实现restful url
而struts2的架构实现起来要费劲
因为struts2 action的一个方法可以对应一个url
而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了
4:
spring3mvc的方法之间基本上独立的，独享request response数据
请求数据通过参数获取，处理结果通过ModelMap交回给框架
方法之间不共享变量
而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的
这不会影响程序运行，却给我们编码 读程序时带来麻烦
5:
由于Struts2需要针对每个Request进行封装，把Request，Session等Servlet生命周期的变量封装成一个一个Map，供给每个Action使用，并保证线程安全。所以在原则上，是比较耗费内存的。
Spring MVC和Struts2有什么区别？
1、Struts2是类级别的拦截， 一个类对应一个request上下文，SpringMVC是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应,。
2、从架构本身上SpringMVC就容易实现restful url,而struts2的架构实现起来要费劲，因为Struts2中Action的一个方法可以对应一个url，而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。
3、由于上述原因，SpringMVC的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架，方法之间不共享变量，而Struts2搞的就比较乱。
4、虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码 读程序时带来麻烦，每次来了请求就创建一个Action，一个Action对象对应一个request上下文。
5、由于Struts2需要针对每个request进行封装，把request，session等servlet生命周期的变量封装成一个一个Map，供给每个Action使用，并保证线程安全，所以在原则上，是比较耗费内存的。
6、 拦截器实现机制上，Struts2有以自己的interceptor机制，SpringMVC用的是独立的AOP方式，这样导致Struts2的配置文件量还是比SpringMVC大。
Struts和spring分别是什么？
通常更多的我们对比 SpringMVC与Struts
把这张图放在这里，我是想说SpringMVC和Struts2真的是不一样的，虽然在都有着核心分发器等相同的功能组件（这些由MVC模式本身决定的）。
为什么SpringMVC会赢得最后的胜利呢？谈几点我自己的看法：
第一、MVC框架的出现是为了将URL从HTTP的世界中映射到JAVA世界中，这是MVC框架的核心功能。而在URL这一点SpringMVC无疑更加优雅。
第二、从设计实现角度来说，我觉得SpringMVC更加清晰。即使我们去对比Struts2的原理图和SpringMVC的类图，它依然很让人困惑，远没有SpringMVC更加直观：
SpringMVC设计思路：将整个处理流程规范化，并把每一个处理步骤分派到不同的组件中进行处理。
这个方案实际上涉及到两个方面：
l 处理流程规范化 —— 将处理流程划分为若干个步骤（任务），并使用一条明确的逻辑主线将所有的步骤串联起来
l 处理流程组件化 —— 将处理流程中的每一个步骤（任务）都定义为接口，并为每个接口赋予不同的实现模式
处理流程规范化是目的，对于处理过程的步骤划分和流程定义则是手段。因而处理流程规范化的首要内容就是考虑一个通用的Servlet响应程序大致应该包含的逻辑步骤：
l 步骤1—— 对Http请求进行初步处理，查找与之对应的Controller处理类（方法） ——HandlerMapping
l 步骤2—— 调用相应的Controller处理类（方法）完成业务逻辑 ——HandlerAdapter
l 步骤3—— 对Controller处理类（方法）调用时可能发生的异常进行处理 ——HandlerExceptionResolver
l 步骤4—— 根据Controller处理类（方法）的调用结果，进行Http响应处理 ——ViewResolver
正是这基于组件、接口的设计，支持了SpringMVC的另一个特性：行为的可扩展性。
第三、设计原则更加明朗。
【Open for extension /closed for modification】
这条重要的设计原则被写在了Spring官方的reference中SpringMVC章节的起始段： A key design principle in SpringWeb MVC and in Spring in general is the “Open for extension, closed for modification” principle.
并且重点很好地体现在SpringMVC的实现当中，可以扩展，但却不能改变。我曾经扩展过Spring的IOC、AOP功能，这一点SpringMVC应该和Spring一脉相承。
第四、组件化的设计方案和特定的设计原则让SpringMVC形散神聚。
神 —— SpringMVC总是沿着一条固定的逻辑主线运行
形 —— SpringMVC却拥有多种不同的行为模式
SpringMVC是一个基于组件的开发框架，组件的不同实现体系构成了“形”；组件的逻辑串联构成了“神”。因此，“形散神不散”： SpringMVC的逻辑主线始终不变，而行为模式却可以多种多样。
第五、更加贴合Web发展的趋势，这个更加虚了，不再展开说这个 问题了。
第六、技术上的放缓导致了程序员对Struts2失去了热情，导致SpringMVC依靠自身的努力和Spring的口碑，逐渐显露了自身的优势和特点。
为什么SpringMVC会赢得最后的胜利呢？最后，我们不妨想一想Struts2是怎样流行起来的！
我自己是从Struts1用过来的，后来Struts1的问题很明显了，开源社区出现了很多的MVC框架，最为突出的是Webwork2。
Webwork2探索了一条与传统Servlet模型不同的解决方案，逐渐被大家熟识和理解，不断发展并得到了广大程序员的认可。它以优秀的设计思想和灵活的实现，吸引了大批的Web层开发人员投入它的 怀抱。
Apache社区与Opensymphony宣布未来的Struts项目将与Webwork2项目合并，并联合推出Struts2。
Struts2能够在一个相当长的时间段内占据开发市场主导地位的重要原因在于其技术上的领先优势。而这一技术上的领先优势，突出表现为对Controller的彻底改造：
public class UserController { private User user public String execute() { // 这里加入业务逻辑代码 return "success"; }}
从上面的代码中，我们可以看到Webwork2 /Struts2对于Controller最大的改造有两点：
在Controller中彻底杜绝引入HttpServletRequest或者HttpServletResponse这样的原生Servlet对象。
将请求参数和响应数据都从响应方法中剥离到了Controller中的属性变量。
这两大改造被看作是框架的神来之笔。因为通过这一改造，整个Controller类彻底与Web容器解耦，可以方便地进行单元测试。而摆脱了Servlet束缚的Controller，也为整个编程模型赋予了全新的定义。从引入新的编程元素的角度来说，Webwork2 / Struts2无疑也是成功的。因为在传统Servlet模式中的禁地Controller中的属性变量被合理利用了起来作为请求处理过程中的数据部分。这样的改造不仅使得表达式引擎能够得到最大限度的发挥，同时使得整个Controller看起来更像是一个POJO。因而，这种表现形态被笔者冠以的名称 是：POJO实现模式。POJO实现模式是一种具有革命性意义的模式，因为它能够把解耦合这样一个观点发挥到极致。从面向对象的角度来看，POJO模式无疑也是所有程序员所追求的一个目标。这也就是Webwork2 /Struts2那么多年来经久不衰的一个重要原因。
所以，我们看到第一条原因是Struts2依靠技术上的革新赢得了程序员的青睐。但是，这些年来Struts2在技术革新上的作为似乎步子就迈得比较小。我们可以看到，在JDK1.5普及之后，Annotation作为一种新兴的Java语法，逐渐 被大家熟知和应用。这一点上SpringMVC紧跟了时代的潮流，直接用于请求-响应的映射。而Struts2却迟迟无法在单一配置源的问题上形成突破。 当然，这只是技术革新上的一个简单的例子，其他的例子还有很多。
至少给人的感觉是这样的。在这一点上Struts并不是很沾光，因为Spring的口碑和影响力也客观程度上加深了大家对SpirngMVC是技术领导者的印象。
spring和struts2的区别是什么？
Struts2
简单来说，就是一个拦截器栈
也就是一系列的拦截器。
处理用户的请求，OGNL的使用，表单验证
等都是默认的拦截器在起作用。
而spring的拦截器，主要体现在AOP的事务管理方面，还有比如一些错误或者异常的日志的显示
也是通过配置spring的log拦截器来实现的。
拦截器
顾名思义
就是拦截一些请求并加以相应的处理。所以广义来说
spring和
struts2的拦截器的工作原理都一样。只是功能不一样而已
struts2和springmvc有什么区别
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一起使用。
spring3mvc与struts2比较
项目刚刚换了web层框架，放弃了struts2改用spring3mvc
当初还框架的时候目的比较单纯---springmvc支持rest，小生对restful url由衷的喜欢
不用不知道 一用就发现开发效率确实比struts2高
我们用struts2时采用的传统的配置文件的方式，并没有使用传说中的0配置
spring3 mvc可以认为已经100%零配置了（除了配置springmvc-servlet.xml外）
比较了一下strus2与spring3 mvc的差别
============================================
struts2框架是类级别的拦截，每次来了请求就创建一个Action，然后调用setter getter方法把request中的数据注入
struts2实际上是通过setter getter方法与request打交道的
struts2中，一个Action对象对应一个request上下文
spring3 mvc不同，spring3mvc是方法级别的拦截，拦截到方法后根据参数上的注解，把request数据注入进去
在spring3mvc中，一个方法对应一个request上下文
好了 我们来整理一下
struts2是类级别的拦截， 一个类对应一个request上下文，
springmvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应
所以说从架构本身上 spring3 mvc就容易实现restful url
而struts2的架构实现起来要费劲
因为struts2 action的一个方法可以对应一个url
而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了
===================================
spring3mvc的方法之间基本上独立的，独享request response数据
请求数据通过参数获取，处理结果通过ModelMap交回给框架
方法之间不共享变量
而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的
这不会影响程序运行，却给我们编码 读程序时带来麻烦
====================================
spring3 mvc的验证也是一个亮点，支持JSR303
处理ajax的请求更是方便 只需一个注解@ResponseBody ，然后直接返回响应文本即可
附上一段代码
Java代码
@RequestMapping(value="/whitelists")
public String index(ModelMap map){
Account account = accountManager.getByDigitId(SecurityContextHolder.get().getDigitId()) ;
List
groupList = groupManager.findAllGroup(account.getId()) ;
map.put("account", account);
map.put("groupList", groupList);
return "/group/group-index" ;
}
//@ResponseBody ajax响应
@RequestMapping(value="/whitelist/{whiteListId}/del")
@ResponseBody
public String delete(@PathVariable Integer whiteListId){
whiteListManager.deleteWhiteList(whiteListId) ;
return "success" ;
}
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一起使用。
1）springmvc的入口是一个servlet，即前端控制器，例如：*.action
struts2入口是一个filter过虑器，即前端过滤器，例如：/*
2）springmvc是基于方法开发，传递参数是通过方法形参，可以设计为单例
struts2是基于类开发，传递参数是通过类的属性，只能设计为多例
3）springmvc通过参数解析器是将request对象内容进行解析成方法形参，将响应数据和页面封装成 ModelAndView对象，最后又将模型数据通过request对象传输到页面
struts采用值栈存储请求和响应的数据，通过OGNL存取数据