Spring MVC体系结构

【Spring MVC类图】
《Spring实战》中：
《Spring3.0就这么简单》中：
【http://blog.csdn.net/gstormspire/article/details/8239182】
==========================================================================

Spring MVC在高并发情况下性能更好，而且对代码的侵入性很少，轻量级的原因使得开发效率比Struts2好。
Spring MVC更加接近“零配置”的目标。

==========================================================================

——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

Struts2优势：
Struts2能够在一个相当长的时间段内占据开发市场主导地位的重要原因在于其技术上的领先优势。而这一技术上的领先优势，突出表现为对Controller的彻底改造：
public class UserController {
private User user
public String execute() {
// 这里加入业务逻辑代码
return "success";
}
}
从上面的代码中，我们可以看到Webwork2 /Struts2对于Controller最大的改造有两点：
1.在Controller中彻底杜绝引入HttpServletRequest或者HttpServletResponse这样的原生Servlet对象。
2.将请求参数和响应数据都从响应方法中剥离到了Controller中的属性变量。

整个Controller类彻底与Web容器解耦，可以方便地进行单元测试。

因为在传统Servlet模式中的禁地Controller中的属性变量被合理利用了起来作为请求处理过程中的数据部分。这样的改造不仅使得表达式引擎能够得到最大限度的发挥，同时使得整个Controller看起来更像是一个POJO。因而，这种表现形态被笔者冠以的名称是：POJO实现模式。POJO实现模式是一种具有革命性意义的模式，因为它能够把解耦合这样一个观点发挥到极致。从面向对象的角度来看，POJO模式无疑也是所有程序员所追求的一个目标。这也就是Webwork2 /Struts2那么多年来经久不衰的一个重要原因。


所以，我们看到第一条原因是Struts2依靠技术上的革新赢得了程序员的青睐。但是，这些年来Struts2在技术革新上的作为似乎步子就迈得比较小。我们可以看到，在JDK1.5普及之后，Annotation作为一种新兴的Java语法，逐渐被大家熟知和应用。这一点上SpringMVC紧跟了时代的潮流，直接用于请求-响应的映射。而Struts2却迟迟无法在单一配置源的问题上形成突破。当然，这只是技术革新上的一个简单的例子，其他的例子还有很多。
至少给人的感觉是这样的。在这一点上Struts并不是很沾光，因为Spring的口碑和影响力也客观程度上加深了大家对SpirngMVC是技术领导者的印象。

【注意】现在的struts2也有自己的注解。

==========================================================================

struts2是类级别的拦截，一个类对应一个request上下文。
springmvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应。所以说从架构本身上 spring3 mvc就容易实现restful url。
而struts2的架构实现起来要费劲，因为struts2 action的一个方法可以对应一个url ，而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。

spring3mvc的方法之间基本上独立的，独享request response数据。请求数据通过参数获取，处理结果通过ModelMap交回给框架。方法之间不共享变量。
而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的。这不会影响程序运行，却给我们编码读程序时带来麻烦。

spring3 mvc的验证也是一个亮点，支持JSR303。处理ajax的请求更是方便只需一个注解@ResponseBody ，然后直接返回响应文本即可。

struts1也一样，运行一个action的方法的时候创建一个action类，以后再运行就不会创建了，其实也是Servlet的封装的框架。
struts2特殊一些，每个请求要new一个action来保证线程安全。所以效率会低一些，但是不会低的特别离谱。
这样也说明了spring3的mvc和struts1的mvc还有Servlet都是方法的线程安全，所以在类方法声明的私有或者公有变量不是线程安全的。struts2的确实是线程安全的。

==========================================================================

1.spring mvc的入口是servlet，而struts2是filter
2.性能：spring会稍微比struts快。spring mvc是基于方法的设计，而sturts是基于类。
【基于类：是指一个URL请求对应于一个action类去处理】
【基于方法：一个请求对应类中的一个方法处理】
3. 参数传递：struts是在接受参数的时候，可以用属性来接受参数，这就说明参数是让多个方法共享的。
4. 设计思想上：struts更加符合oop的编程思想， spring就比较谨慎，在servlet上扩展。
5. intercepter的实现机制：struts有以自己的interceptor机制，spring mvc用的是独立的AOP方式。
6. 另外，spring3 mvc的验证也是一个亮点，支持JSR303，处理ajax的请求更是方便，只需一个注解@ResponseBody ，然后直接返回响应文本即可。