springMVC

一 、什么是springMVC

1.是对Servlet封装（体现在继承上面）

解决Servlet内容太多、繁杂。。。

然后在web.xml有个自动配置，通过component

2.对视图层转发、分发

Spring MVC是Spring提供的一个实现了Web MVC设计模式的轻量级Web框架。它与Struts2框架一样，都属于MVC框架，但其使用和性能等方面比Struts2更加优异。在实际开发中，接收浏览器的请求响应，对数据进行处理，然后返回页面进行显示，但是上手难度却比 Struts2 简单多了。而且由于 Struts2 所暴露出来的安全问题，SpringMVC 已经成为了大多数企业优先选择的框架。

单独的servlet配合tomcat容器就能够实现web服务。但是单独的servlet开发其配置信息会过度臃肿，开发效率低下。随着使用的人越来越多，慢慢就出现了解决开发效率、简化开发配置的框架，比如structs,springMVC等mvc框架。所以实际上springMVC是对servlet的封装,springMVC的核心控制类DispatcherServlet 实际是对 HttpServlet的继承

Spring Web MVC也是服务到工作者模式的实现，但进行可优化。前端控制器是DispatcherServlet；应用控制器其实拆为处理器映射器(Handler Mapping)进行处理器管理和视图解析器(View Resolver)进行视图管理；页面控制器/动作/处理器为Controller接口（仅包含ModelAndView handleRequest(request, response) 方法）的实现（也可以是任何的POJO类）；支持本地化（Locale）解析、主题（Theme）解析及文件上传等；提供了非常灵活的数据验证、格式化和数据绑定机制；提供了强大的约定大于配置（惯例优先原则）的契约式编程支持。

二、MVC的发展史

在早期 Java Web 的开发中，统一把显示层、控制层、数据层的操作全部交给 JSP （java服务器页面）或者 JavaBean 来进行处理，我们称之为 Model1：

出现的弊端：

• JSP 和 Java Bean 之间严重耦合，Java 代码和 HTML 代码也耦合在了一起
• 要求开发者不仅要掌握 Java ，还要有高超的前端水平
• 前端和后端相互依赖，前端需要等待后端完成，后端也依赖前端完成，才能进行有效的测试(前后端未分离)
• 代码难以复用

正因为上面的种种弊端，所以很快这种方式就被 Servlet + JSP + Java Bean 所替代了，早期的 MVC 模型**（Model2）**就像下图这样：

首先用户的请求会到达 Servlet，然后根据请求调用相应的 Java Bean，并把所有的显示结果交给 JSP 去完成，这样的模式我们就称为 MVC 模式。

M 代表 模型（Model）
模型是什么呢？ 模型就是数据，就是 dao,bean

V 代表 视图（View）
视图是什么呢？ 就是网页, JSP，用来展示模型中的数据

C 代表 控制器（controller)
控制器是什么？ 控制器的作用就是把不同的数据(Model)，显示在不同的视图(View)上，Servlet 扮演的就是这样的角色（知道在哪个controller哪个value，从而找到路径）。

Spring MVC 的架构

为解决持久层中一直未处理好的数据库事务的编程，又为了迎合 NoSQL 的强势崛起，Spring MVC 给出了方案：

传统的模型层被拆分为了业务层(Service)和数据访问层（DAO,Data Access Object）。 在 Service 下可以通过 Spring 的声明式事务操作数据访问层，而在业务层上还允许我们访问 NoSQL ，这样就能够满足异军突起的 NoSQL 的使用了，它可以大大提高互联网系统的性能。

• 特点：
  结构松散，几乎可以在 Spring MVC 中使用各类视图
  松耦合，各个模块分离
  与 Spring 无缝集成

Spring MVC 的请求流程

第一站：DispatcherServlet

从请求离开浏览器以后，第一站到达的就是 DispatcherServlet，看名字这是一个 Servlet，通过 J2EE 的学习，我们知道 Servlet 可以拦截并处理 HTTP 请求，DispatcherServlet 会拦截所有的请求，并且将这些请求发送给 Spring MVC 控制器。

• DispatcherServlet 的任务就是拦截请求发送给 Spring MVC 控制器。

第二站：处理器映射（HandlerMapping）

• 问题： 典型的应用程序中可能会有多个控制器，这些请求到底应该发给哪一个控制器呢？

所以 DispatcherServlet 会查询一个或多个处理器映射来确定请求的下一站在哪里，处理器映射会根据请求所携带的 URL 信息来进行决策，例如我们通过配置 simpleUrlHandlerMapping 来将 /hello 地址交给 helloController 处理：

第三站：控制器

一旦选择了合适的控制器， DispatcherServlet 会将请求发送给选中的控制器，到了控制器，请求会卸下其负载（用户提交的请求）等待控制器处理完这些信息：

第四站：返回 DispatcherServlet

当控制器在完成逻辑处理后，通常会产生一些信息，这些信息就是需要返回给用户并在浏览器上显示的信息，它们被称为模型（Model）。仅仅返回原始的信息时不够的——这些信息需要以用户友好的方式进行格式化，一般会是 HTML，所以，信息需要发送给一个视图（view），通常会是 JSP。

控制器所做的最后一件事就是将模型数据打包，并且表示出用于渲染输出的视图名**（逻辑视图名）。它接下来会将请求连同模型和视图名发送回 DispatcherServlet。**

第五站：视图解析器

这样以来，控制器就不会和特定的视图相耦合，传递给DispatcherServlet 的视图名并不直接表示某个特定的 JSP。（实际上，它甚至不能确定视图就是 JSP）相反，它传递的仅仅是一个逻辑名称，这个名称将会用来查找产生结果的真正视图。

DispatcherServlet 将会使用视图解析器（view resolver）来将逻辑视图名匹配为一个特定的视图实现，它可能是也可能不是 JSP

第六站：视图

既然 DispatcherServlet 已经知道由哪个视图渲染结果了，那请求的任务基本上也就完成了。

它的最后一站是视图的实现，在这里它交付模型数据，请求的任务也就完成了。视图使用模型数据渲染出结果，这个输出结果会通过响应对象传递给客户端。