SpringMvc学习笔记（一）

前言

项目最先用到了.Net MVC，其实我的Web开发经历一开始就是MVC模式，学习SpringMvc的过程中，也发现很多类似之处，学习SpringMvc过程中更注重原理，之前更注重使用。下面记录学习的一些体会。

SpringMvc框架原理

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

SpringMvc中有一些组件包括：前端控制器、处理器映射器、处理器适配器、视图解析器。

前端控制器（DispatcherServlet）：接收请求，响应结果，相当于电脑的CPU。
处理器映射器（HandlerMapping）：根据URL去查找处理器
处理器（Handler）：（需要程序员去写代码处理逻辑的）
处理器适配器（HandlerAdapter）：会把处理器包装成适配器，这样就可以支持多种类型的处理器，类比笔记本的适配器（适配器模式的应用）
视图解析器（ViewResovler）：进行视图解析，多返回的字符串，进行处理，可以解析成对应的页面

运行的框架图如下：

运行的步骤可以概述如下：

第一步：发起请求到前端控制器(DispatcherServlet)

第二步：前端控制器请求HandlerMapping查找 Handler可以根据xml配置、注解进行查找

第三步：处理器映射器HandlerMapping向前端控制器返回Handler执行链。

第四步：前端控制器调用处理器适配器去执行Handler

第五步：处理器适配器去执行Handler（需人为编写的Handler得实现适配器的相关接口）

第六步：Handler执行完成给适配器返回ModelAndView

第七步：处理器适配器向前端控制器返回ModelAndViewModelAndView是springmvc框架的一个底层对象，包括 Model和view

第八步：前端控制器请求视图解析器去进行视图解析根据逻辑视图名解析成真正的视图(jsp)

第九步：视图解析器向前端控制器返回View

第十步：前端控制器进行视图渲染视图渲染，就是将模型数据(在ModelAndView对象中)填充到request域

第十一步：前端控制器向用户响应结果

初识源码

SpringMVC接口解释

DispatcherServlet接口：
Spring提供的前端控制器，所有的请求都有经过它来统一分发。在DispatcherServlet将请求分发给Spring Controller之前，需要借助于Spring提供的HandlerMapping定位到具体的Controller。
HandlerMapping接口：
能够完成客户请求到Controller映射。
Controller接口：
需要为并发用户处理上述请求，因此实现Controller接口时，必须保证线程安全并且可重用。
Controller将处理用户请求，这和Struts Action扮演的角色是一致的。一旦Controller处理完用户请求，则返回ModelAndView对象给DispatcherServlet前端控制器，ModelAndView中包含了模型（Model）和视图（View）。
从宏观角度考虑，DispatcherServlet是整个Web应用的控制器；从微观考虑，Controller是单个Http请求处理过程中的控制器，而ModelAndView是Http请求过程中返回的模型（Model）和视图（View）。
ViewResolver接口：
Spring提供的视图解析器（ViewResolver）在Web应用中查找View对象，从而将相应结果渲染给客户。

执行过程

第一步：前端控制器接收请求，调用doDiapatch方法

第二步：前端控制器调用处理器映射器查找 Handler，getHandler方法根据url找到执行链，包括拦截器和控制器。

第三步：调用处理器适配器执行Handler，得到执行结果ModelAndView

第四步：视图渲染，view的render方法，将model数据填充到request域。

使用

首先前端控制器是一个DispatcherServlet，要在web.xml中配置。这里类似Servlet的配置，可以参考博文：JavaWeb工程中web.xml基本配置。
servlet中声明的springmvc.xml中需要配置处理器映射器、处理器适配器、视图解析器。这些都是接口抽象类高扩展性的编写方式，非注解模式一般使用simpleControllerHandlerAdapter作为适配器，BeanForNameHadnlerMapping作为映射器（根据bean的name作为url来查找，这就需要配置）。视图解析器使用InternalResourceViewSolver，能够解析jsp。现在一般使用注解模式。
编写hadler，即实现controller接口的业务逻辑处理类，返回ModelAndView。
前台页面编写。

SpringMvc和Mybatis整合

整合思想如下：

第一步：整合dao层

mybatis和spring整合，通过spring管理mapper接口。

使用mapper的扫描器自动扫描mapper接口在spring中进行注册。

第二步：整合service层

通过spring管理 service接口。

使用配置方式将service接口配置在spring配置文件中。

实现事务控制。

第三步：整合springmvc

由于springmvc是spring的模块，不需要整合。

tip

视图解析器可以配置前缀和后缀。
前台往后台传值，后台往前台传值的参数绑定和使用方式。

springmvc和struts2区别

Struts2是类级别的拦截，一个类对应一个request上下文，SpringMVC是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应,所以说从架构本身上SpringMVC就容易实现restful url,而struts2的架构实现起来要费劲，因为Struts2中Action的一个方法可以对应一个url，而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。
由上边原因，SpringMVC的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架，方法之间不共享变量，而Struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码读程序时带来麻烦，每次来了请求就创建一个Action，一个Action对象对应一个request上下文。
由于Struts2需要针对每个request进行封装，把request，session等servlet生命周期的变量封装成一个一个Map，供给每个Action使用，并保证线程安全，所以在原则上，是比较耗费内存的。
拦截器实现机制上，Struts2有以自己的interceptor机制，SpringMVC用的是独立的AOP方式，这样导致Struts2的配置文件量还是比SpringMVC大。
SpringMVC的入口是servlet，而Struts2是filter（这里要指出，filter和servlet是不同的。以前认为filter是servlet的一种特殊），这就导致了二者的机制不同，这里就牵涉到servlet和filter的区别了。
SpringMVC集成了Ajax，使用非常方便，只需一个注解@ResponseBody就可以实现，然后直接返回响应文本即可，而Struts2拦截器集成了Ajax，在Action中处理时一般必须安装插件或者自己写代码集成进去，使用起来也相对不方便。
SpringMVC验证支持JSR303，处理起来相对更加灵活方便，而Struts2验证比较繁琐，感觉太烦乱。
spring MVC和Spring是无缝的。从这个项目的管理和安全上也比Struts2高（当然Struts2也可以通过不同的目录结构和相关配置做到SpringMVC一样的效果，但是需要xml配置的地方不少）。
设计思想上，Struts2更加符合OOP的编程思想， SpringMVC就比较谨慎，在servlet上扩展。
SpringMVC开发效率和性能高于Struts2。
SpringMVC可以认为已经100%零配置。