Marco's Java【SpringMVC入门(一) 之 SpringMVC简介】

前言

在系统的讲解了SSM三兄弟的Spring大哥和Mybatis三弟之后，我们本篇章重点来了解排行第二的SpringMVC，那按照老规矩，先做个自我介绍吧~

什么是SpringMVC

我们先来看一张比较经典的图，我们发现SpringMVC是被分割到Web中的，那么他和Web开发肯定是有着某种关联的

SpringMVC的全称是Spring Model-View-Controller，从名字上不难看出两点
第一点，他和Spring是亲兄弟，可见Spring家族是多么庞大！
第二点，从Model-View-Controller看出，它包揽了从模型到视图到控制层面的所有支配管理任务，细节上由Spring和Mybatis管理，SpringMVC的地盘就是Servlet，那么它的功能主要就涉及到Servlet和页面的信息传输，因此，这个节点也是不可或缺的。

接下来我们看看关于SpringMVC的概述吧~

概述：
Spring MVC是Spring提供的一个强大而灵活的web框架。借助于注解，Spring MVC提供了几乎是POJO的开发模式，使得控制器的开发和测试更加简单。这些控制器一般不直接处理请求，而是将其委托给Spring上下文中的其他bean，通过Spring的依赖注入功能，这些bean被注入到控制器中。

Spring MVC(车子)主要由DispatcherServlet、处理器映射、处理器(控制器)、视图解析器、视图组成。
两个核心(轮子)：
处理器映射：选择使用哪个控制器来处理请求
视图解析器：选择结果应该如何渲染
通过下面的这张图基本上可以诠释了Spring MVC的结构，是不是很形象？哈哈

SpringMVC的实现原理

既然我们初步的了解了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对象，从而将相应结果渲染给客户。

来分析一下，我们把SpringMVC当作是一个大公司，浏览器就是客户，客户去公司找人，首先要经过大门吧，但是客户只知道想找的人的英文名字，因为SpringMVC是一家外企，但是不知道他具体在哪个部门，所以就跑到门卫大叔那里去问，“大叔，你知道Jackie Chan在哪个办公室吗？”，门卫大叔根本不懂英文啊，所以就要去花名册去找这个Jackie Chan到底是谁，在哪个办公区域。
找了半天，终于找到了，“你要找的Jackie Chan叫成龙是吧，那我带你去找他吧！”

其实通过这个栗子，我们不难发现，DispatcherServlet是一个很重要的角色，他是整个Web的控制器，也就是我们的"门卫大叔"，那么客户想找某个人并询问"门卫大叔"就相当于发出了一个请求，那么我们可以想想，"门卫大叔"DispatcherServlet这个角色，那肯定是在这个请求发过来之前就得有的吧！

大家之前学习过Servlet应该知道，我们的Servlet的生命周期是从客户端发出请求才开始的，这种方式称为懒加载，但是试想一下，"门卫大叔"这个角色能懒加载吗？难道是等客户来了，我随随便便再去招聘一个？
显然是不可行的，因此后面一节我们会讲到"门卫大叔"怎么在客户来公司找人之前就生成的。