本文转于：https://wk.baidu.com/view/44e3457583c4bb4cf7ecd191#2

虽然说没有系统的学习过Spring MVC框架, 但是工作这么长时间, 基本上在WEB层使用的都是Spring MVC, 自己觉得Struts2也是一个不错的WEB层框架, 这两种框架至今自己还未有比较, 今天闲着没事干, 从网上找了一些资料, 再加上平时使用Spring MVC的感触来总结一下。 Spring MVC PK Struts2 我们用struts2时采用的传统的配置文件的方式，并没有使用传说中的0配置。spring3 mvc可以认为已经100%零配置了（除了配置spring mvc-servlet.xml外）。 

Spring MVC和Struts2的区别： 

1. 机制：spring mvc的入口是servlet，而struts2是filter（这里要指出，filter和servlet是不同的。以前认为filter是servlet的一种特殊），这样就导致了二者的机制不同，这里就牵涉到servlet和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上扩展。 

5. intercepter的实现机制：struts有以自己的interceptor机制，spring mvc用的是独立的AOP方式。这样导致struts的配置文件量还是比spring mvc大，虽然struts的配置能继承，所以我觉得论使用上来讲，spring mvc使用更加简洁，开发效率Spring MVC确实比struts2高。spring mvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应，所以说从架构本身上spring3
 mvc就容易实现restful url。struts2是类级别的拦截，一个类对应一个request上下文；实现restful url要费劲，因为struts2 action的一个方法可以对应一个url；而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。spring3 mvc的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架方法之间不共享变量，而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码，读程序时带来麻烦。 

6. 另外，sp

SpringMVC和Struts2的区别

（多例）Struts2是一个请求一个Action,     （Struts2接收的参数是通过类的成员变量来接收的，这些变量在多线程访问中，是共享的，而不是像SpringMVC那样，方法结束之后，形参自动销毁，且无法使用单例，只能使用多例。 在Struts2中，随着方法的添加，很多的成员变量，维护到最后的时候根本就不知道这个成员变量被哪个方法所使用，所以springMVC开发类似于service开发）                                                                                                                                        （单例）SpringMVC是单例模式的（SpringMVC在映射的时候，通过形参来接收参数的，是将url和controller方法映射，映射成功后，SpringMVC生成一个handlers对象，对象中只包括一个method，方法执行结束的时候，形参的数据就销毁，建议使用）
	
Struts2是基于类的横切，     SpringMVC基于方法（可以和上一条结合起来）粒度更细
	
一个入口是Filter，一个入口是Servlet。则两者各个方面机制不同，比如拦截器实现机制
	
SpringMVC开发速度和性能较优于Struts2，流程更容易理解                                                                                                Struts速度慢，使用struts标签，建议使用jstl。
	
Spring体系更加强大和活跃
 

MyBatis和Hibernate的区别

1、hibernate 入门门槛高，是一个标准的ORM矿建（对象关系映射），不需要程序写sql，sql语句自动生成，对sql语句进行优化、修改比较困难。hql语句

　  mybatis专注于sql本身，需要程序员自己编写sql语句，sql修改、优化比较方便。是一个不完全的ORM框架，虽然程序员自己写sql，mybatis也可以实现映射（输入映射，输出映射）

应用场景方面：

2、hibernate适用于需求变化不多的中小型项目，比如：后台管理系统，orm、oa......

　　mybatis适用于需求变化较多的项目，比如：互联网项目。

 

 

 

springMVC是方法级别的拦截，struts2是基于类级别的拦截
	
Struts2有以自己的interceptor机制，SpringMVC用的是独立的AOP方式，这样导致 Struts2的配置文件量还是比SpringMVC大
	
SpringMVC的入口是servlet，而Struts2是filter


简单介绍一下Struts2的值栈？

值栈是对应每一个请求对象的数据存储中心。Struts2的一个很重要的特点就是引入了值栈。之前我们通过缓存或者模型驱动在action和页面之间传递数据，数据混乱，并且难以管理，缓存还有时间和数量限制，使用起来非常的困难。值栈的引入解决了这个问题，它可以统一管理页面和action之间的数据，供action、result、interceptor等使用。我们大多数情况下不需要考虑值栈在哪里，里面有什么，只需要去获取自己需要的数据就可以了，大大的降低了开发人员的工作量和逻辑复杂性。


 

   4 .SpringMVC开发效率和性能高于Struts2  (体现以下几个方面） 

) Struts2每次来了请求就创建一个Action，一个Action对象对应一个request上下 文 ，消耗内存
	
) 由于Struts2需要针对每个request进行封装，把request，session等servlet 生命周期的变量封装成一个一个Map，供   给每个Action使用（这就解释了为什么struts2获取这些属性值比较方便 快捷的原因），并保证线程安全， 所以在原则上，是比较耗费内存的）
	
)SpringMVC的入口是servlet，而Struts2是filter 
             Servlet的流程比较短，url来了之后就对其进行处理，处理安慰你就返回数据或者 转向另一个页面

             Filter的流程就比较长，在一个filter处理之后就可以转向另一个filter进行处理， 然后再交给servet

 

目前企业中使用SpringMvc的比例已经远远超过Struts2,那么两者到底有什么区别，是很多初学者比较关注的问题，下面我们就来对SpringMvc和Struts2进行各方面的比较:
1. 核心控制器（前端控制器、预处理控制器）：对于使用过mvc框架的人来说这个词应该不会陌生，核心控制器的主要用途是处理所有的请求，然后对那些特殊的请求（控制器）统一的进行处理(字符编码、文件上传、参数接受、异常处理等等),springmvc核心控制器是Servlet，而Struts2是Filter。
2.控制器实例：Spring Mvc会比Struts快一些（理论上）。Spring
 Mvc是基于方法设计，而Sturts是基于对象，每次发一次请求都会实例一个action，每个action都会被注入属性，而Spring更像Servlet一样，只有一个实例，每次请求执行对应的方法即可(注意：由于是单例实例，所以应当避免全局变量的修改，这样会产生线程安全问题)。
补充一下：
1.struts2的Action默认是多实例的并非单例，也就是每次请求产生一个Action的对象,即每次访问的参数都被封装在Action的成员变量中。
 
2.struts2中Action多实例的优势在于是线程安全的，每次请求都会创建单独的Action类来处理，而不用想servlet一样担心线程安全问题。
struts2和spring整合后会使用spring的注解管理对象，此时action类对象会进入IOC容器被spring管理
尽管struts2本身Action默认是多例的，但spring的IOC容器默认时单例，此时就矛盾了？
那么内部是如何处理的呢？
Spring管理Struts2的Action自动设置为单例。这样Action的生命周期为服务器生命周期，也就是说不关闭应用服务器，Action一直存在，Action中的属性也一直存在。
 
这样做的好处:
分页对象所需要的数据对象存在于Action中是不被销毁的，直到页面重新对数据对象输入查询条件.
 
这样做的缺点在于:
1) Struts2的Action是单例,其中的FieldError,actionerror中的错误信息会累加,即使再次输入了正确的信息,也过不了验证.
2) Struts2的Action是有状态的,他有自己的成员属性,所以在多线程下,会有线程安全问题，这是最大的问题。
多个线程会共享一个ActionContext和ValueStack，这样并发访问的时候就会出现问题了.例如造成别人填写的数据被你看到了.又例如，两个线程同时提交向同一个Action提前请求参数或在同一个页面上查询信息，会在提交和查询的先后顺序等条件上产生冲突，导致出来一些意外的问题。
 
解决办法：
方案一: 就是不用单例, spring中bean的作用域设为prototype,每个请求对应一个Action实例.(建议这样做)
 
方案二: spring中bean的作用域设为session ,每个session对应一个实例,解决了多线程问题.
 
总结 :
方案一：bean的作用域设为prototype,
不用担心性能不好, 
实际测试过,多实例Action性能没问题.
方案二: 有人担心方案一性能不好，所有才有了方案二,
不知比方案一性能能高多少？应该不会高多少。
 
3. 管理方式：大部分的公司的核心架构中，就会使用到spring,而spring mvc又是spring中的一个模块，所以spring对于spring
 mvc的控制器管理更加简单方便，而且提供了全注解方式进行管理，各种功能的注解都比较全面，使用简单，而struts2需要采用XML很多的配置参数来管理（虽然也可以采用注解，但是几乎没有公司那样使用）。
4.参数传递：Struts2中自身提供多种参数接受，其实都是通过（ValueStack）进行传递和赋值，而SpringMvc是通过方法的参数进行接收。
5.学习难度：Struts更加很多新的技术点，比如拦截器、值栈及OGNL表达式，学习成本较高，springmvc比较简单，很较少的时间都能上手。
6.intercepter 的实现机制：struts有以自己的interceptor机制，spring
 mvc用的是独立的AOP方式。这样导致struts的配置文件量还是比spring mvc大，虽然struts的配置能继承，所以我觉得论使用上来讲，spring
 mvc使用更加简洁，开发效率Spring MVC确实比struts2高。spring mvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应，所以说从架构本身上spring3
 mvc就容易实现restful url。struts2是类级别的拦截，一个类对应一个request上下文；实现restful
 url要费劲，因为struts2 action的一个方法可以对应一个url；而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。spring3
 mvc的方法之间基本上独立的，独享requestresponse数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架方法之间不共享变量，而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码，读程序时带来麻烦。
7.spring mvc处理ajax请求,直接通过返回数据，方法中使用注解@ResponseBody，spring
 mvc自动帮我们对象转换为JSON数据。
 
可以谈一谈Struts2 和SpringMVC 在请求-响应模型的上的区别。

--------------------------------------------

Struts2处理请求是为每个请求都创建一个单独的Action类，Action类当中的Field属性参数作为输入和输出参数用IOC来依赖注入的方式，是基于类的。


而SpringMVC则采用输入Request和Reponse作为参数，返回ModelAndView的方式，是单例的模式，且是基于方法的模式。

---------------------------------------------------------------------




下面这些东西基本都是我从网上粘贴过来的，没有那么多耐心和时间一个字一个字的敲了，但是基本能表明我选择SpringMVC的思路和原因。

把这张图放在这里，我是想说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 andin 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是技术领导者的印象。