Spring MVC 是什么 （了解）
Spring MVC（全称 Spring Web MVC）是 Spring 框架提供的一款基于 MVC 模式的轻量级 Web 开发框架，是 Spring 为表示层（UI）开发提供的一整套完备的解决方案。Spring MVC 使用 MVC 架构模式的思想，将 Web 应用进行职责解构，把一个复杂的 Web 应用划分成模型（Model）、控制器（Contorller）以及视图（View）三层，有效地简化了 Web 应用的开发，降低了出错风险，同时也方便了开发人员之间的分工配合。
注：三层架构分为表示层（UI）、业务逻辑层（BLL）、数据访问层（DAL），表示层则包含前台页面和后台 Servlet
Spring MVC 各层的职责如下：
Model：负责对请求进行处理，并将结果返回给 Controller；
View：负责将请求的处理结果进行渲染，展示在客户端浏览器上；
Controller：是 Model 和 View 交互的纽带；主要负责接收用户请求，并调用 Model 对请求处理，然后将 Model 的处理结果传递给 View。
Spring MVC 本质是对 Servlet 的进一步封装，其最核心的组件是 DispatcherServlet，它是 Spring MVC 的前端控制器，主要负责对请求和响应的统一地处理和分发。Controller 接收到的请求其实就是 DispatcherServlet 根据一定的规则分发给它的。
Spring MVC 框架内部采用松耦合、可插拔的组件结构，具有高度可配置性，比起其他的 MVC 框架更具有扩展性和灵活性。此外，Spring MVC 的注解驱动（annotation-driven）和对 REST 风格的支持，也是它最具有特色的功能。
Spring MVC 的常用组件
Spring MVC 的常用组件如下表。
Spring MVC 的特点
Spring MVC 具有以下特点：
Spring MVC 是 Spring 家族原生产品，可以与 IoC 容器等 Spring 基础设施无缝对接；
Spring MVC 支持各种视图技术，例如 JSP、Thymeleaf、 JSP 和 FreeMaker 等。
Spring MVC 基于原生的 Servlet 实现，通过功能强大的前端控制器 DispatcherServlet，对请求和响应进行统一处理；
Spring MVC 对表示层各细分领域需要解决的问题全方位覆盖，并提供一整套全面的解决方案；
代码清新简洁，大幅度提升开发效率；
内部组件化程度高，可插拔式组件即插即用，想要使用什么功能，配置相应组件即可；
性能卓著，尤其适合现代大型、超大型互联网项目的开发。
MVC 设计模式 （了解）
MVC 模式，全称为 Model-View-Controller（模型-视图-控制器）模式，它是一种软件架构模式，其目标是将软件的用户界面（即前台页面）和业务逻辑分离，使代码具有更高的可扩展性、可复用性、可维护性以及灵活性。
通常情况下，一个完整的 Java Web 应用程序，其结构如下图所示。
图1：Java Web 应用的结构
MVC 模式将应用程序划分成模型（Model）、视图（View）、控制器（Controller）等三层，如下图所示。
图2：MVC 模式
MVC模式 VS 三层架构
和 MVC 模式类似，三层架构同样将系统划分成了 3 层：
表示层（UI）：用来实现与用户的交互，接收用户请求，并将请求交给业务逻辑层（BLL）和数据访问层（DAL）进行处理，最后将处理结果返回给用户。
业务逻辑层（BLL）：起到承上启下的作用，接收表示层传递来的请求，并针对业务对数据进行处理，以实现业务目标。
数据访问层（DAL）：用于实现与数据库的交互和访问，例如从数据库中获取数据、保存或修改数据库中的数据等。
虽然三层架构和 MVC 模式一样，都是将应用划分成了 3 层，但它们的划分方式是不同的。
下图展示了三层架构的划分方式，我们可以很清楚地分辨出它与 MVC 模式的不同。
图3：三层架构
从上图可以看出，三层架构是由表示层（UI）、业务逻辑层（BLL）和数据访问层（DAL）三个层次构成的，而 MVC 则是由视图（View）层、控制（Controller）层以及模型（Model）层，且它们之间并不是一一对应的。
三层架构和 MVC 模式中各层对应关系如下：
三层架构中的表示层（UI）包含 HTML、JSP 等前台页面以及后台的 Servlet，即它相当于 MVC 模式中的 View 层 + Controller 层。
三层架构中的业务逻辑层（BLL），则只包含了 Service 接口及其实现类（Servicelmpl）的代码，即它相当于 MVC 模式中 Model 层的一部分，并不包含 Dao 和实体类。
三层架构中的数据访问层（DAL），则只包含了 Dao 接口及其实现类（DaoImpl）的代码，即它相当于 MVC 模式中 Model 层的一部分，并不包含 Service 和实体类。
三层架构将应用中的各个模块划分为表示层（UI）、业务逻辑层（BLL）和数据访问层（DAL）等三层，各层之间采用接口相互访问，并通过实体类作为数据传递的载体。不同的实体类一般对应于数据库中不同的数据表，且实体类的属性与数据库表的字段名一一对应 。
从上面的划分方式来看，三层架构和 MVC 模式确实是不一样的，但从它们的核心来看，两者又是一样的，它们的核心都是“分层、解耦”。
MVC 的工作流程
MVC 的工作流程如下：
1.用户发送请求到服务器；
2.在服务器中，请求被控制层（Controller）接收；
3.Controller 调用相应的 Model 层处理请求；
4.Model 层处理完毕将结果返回到 Controller；
5.Controller 再根据 Model 返回的请求处理结果，找到相应的 View 视图；
6.View 视图渲染数据后最终响应给浏览器。
MVC 的优点
MVC 模式具有以下优点：
降低代码耦合性：在 MVC 模式中，三层之间相互独立，各司其职。一旦某一层的需求发生了变化，我们就只需要更改相应层中的代码即可，而不会对其他层中的代码造成影响。
有利于分工合作：在 MVC 模式中，将应用系统划分成了三个不同的层次，可以更好地实现开发分工。例如，网页设计人员专注于视图（View）层的开发，而那些对业务熟悉的开发人员对 Model 层进行开发，其他对业务不熟悉的开发人员则可以对 Controller 层进行开发。
有利于组件的重用：在 MVC 中，多个视图（View）可以共享同一个模型（Model），大大提高了系统中代码的可重用性。
MVC 的不足
MVC 模式存在以下不足之处：
增加了系统结构和实现的复杂性：对于简单的应用，如果也严格遵循 MVC 模式，按照模型、视图与控制器对系统进行划分，无疑会增加系统结构的复杂性，并可能产生过多的更新操作，降低运行效率。
视图与控制器间的联系过于紧密：虽然视图与控制器是相互分离的，但它们之间联系却是十分紧密的。视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了它们的独立重用。
视图对模型数据的低效率访问：视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
MVC 并不适合小型甚至中型规模的项目，花费大量时间将 MVC 应用到规模并不是很大的应用程序中，通常会得不偿失，因此对于 MVC 设计模式的使用要根据具体的应用场景来决定
Spring MVC 和 Struts2的区别（了解）
一、拦截机制的不同
Struts2是类级别的拦截，每次请求就会创建一个Action，和Spring整合时Struts2的ActionBean注入作用域是原型模式prototype，然后通过setter，getter吧request数据注入到属性。Struts2中，一个Action对应一个request，response上下文，在接收参数时，可以通过属性接收，这说明属性参数是让多个方法共享的。Struts2中Action的一个方法可以对应一个url，而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了，只能设计为多例。
SpringMVC是方法级别的拦截，一个方法对应一个Request上下文，所以方法直接基本上是独立的，独享request，response数据。而每个方法同时又何一个url对应，参数的传递是直接注入到方法中的，是方法所独有的。处理结果通过ModeMap返回给框架。在Spring整合时，SpringMVC的Controller Bean默认单例模式Singleton，所以默认对所有的请求，只会创建一个Controller，有应为没有共享的属性，所以是线程安全的，如果要改变默认的作用域，需要添加@Scope注解修改。
Struts2有自己的拦截Interceptor机制，SpringMVC这是用的是独立的Aop方式，这样导致Struts2的配置文件量还是比SpringMVC大。
二、底层框架的不同
Struts2采用Filter（StrutsPrepareAndExecuteFilter）实现，SpringMVC（DispatcherServlet）则采用Servlet实现。Filter在容器启动之后即初始化；服务停止以后坠毁，晚于Servlet。Servlet在是在调用时初始化，先于Filter调用，服务停止后销毁。
三、性能方面
Struts2是类级别的拦截，每次请求对应实例一个新的Action，需要加载所有的属性值注入，SpringMVC实现了零配置，由于SpringMVC基于方法的拦截，有加载一次单例模式bean注入。所以，SpringMVC开发效率和性能高于Struts2。
四、配置方面
spring MVC和Spring是无缝的。从这个项目的管理和安全上也比Struts2高。
附注：拦截器与过滤器的区别 ：
1.拦截器是基于java的反射机制的，而过滤器是基于函数回调。
2.拦截器不依赖与servlet容器，过滤器依赖与servlet容器。
3.拦截器只能对action请求起作用，而过滤器则可以对几乎所有的请求起作用。
4.拦截器可以访问action上下文、值栈里的对象，而过滤器不能访问。
5.在action的生命周期中，拦截器可以多次被调用，而过滤器只能在容器初始化时被调用一次
*Spring MVC 视图解析器（熟悉）
好文参考：https://www.cnblogs.com/lixiuming521125/p/16000192.html
好文参考：https://www.cnblogs.com/diumyself/p/16223554.html
好文参考：https://blog.csdn.net/howeres/article/details/124941519
好文参考：https://blog.csdn.net/Eaeyson/article/details/125205228
Spring MVC 执行流程 （熟悉）
Spring MVC 执行流程如图 1 所示。
图1：Spring MVC 工作流程
SpringMVC 的执行流程如下
1.用户通过浏览器发起一个 HTTP 请求，该请求会被 DispatcherServlet（前端控制器）拦截；
2.DispatcherServlet 调用 HandlerMapping（处理器映射器）找到具体的处理器（Handler）及拦截器，最后以 HandlerExecutionChain 执行链的形式返回给 DispatcherServlet。
3.DispatcherServlet 将执行链返回的 Handler 信息发送给 HandlerAdapter（处理器适配器）；
4.HandlerAdapter 根据 Handler 信息找到并执行相应的 Handler（即 Controller 控制器）对请求进行处理；
5.Handler 执行完毕后会返回给 HandlerAdapter 一个 ModelAndView 对象（Spring MVC 的底层对象，包括 Model 数据模型和 View 视图信息）；
6.HandlerAdapter 接收到 ModelAndView 对象后，将其返回给 DispatcherServlet ；
7.DispatcherServlet 接收到 ModelAndView 对象后，会请求 ViewResolver（视图解析器）对视图进行解析；
8.ViewResolver 解析完成后，会将 View 视图并返回给 DispatcherServlet；
9.DispatcherServlet 接收到具体的 View 视图后，进行视图渲染，将 Model 中的模型数据填充到 View 视图中的 request 域，生成最终的 View（视图）；
10.视图负责将结果显示到浏览器（客户端）。
Spring MVC 常用组件
Spring MVC 的常用组件共有 6 个，它们分别是： DispatcherServlet（前端控制器）、HandlerMapping（处理器映射器）、HandlerAdapter（处理器适配器）、Handler（处理器）、ViewResolver（视图解析器）和 View（视图）。
下表对各个组件的功能说明如下
@Controller 和@RequestMapping 注解（熟悉）
@Controller 注解
@Controller 注解可以将一个普通的 Java 类标识成控制器（Controller）类，示例代码如下。
package net.biancheng.controller; import org.springframework.stereotype.Controller; @Controller public class IndexController { // 处理请求的方法 }
在一个类上添加@Controller注解，表明了这个类是一个控制器类，可以支持同时处理多个请求。Spring使用扫描机制查找应用程序中所有用了这个注解的控制器类。分发处理器会扫描使用了该注解的类的方法，并检测该方法是否使用了@RequestMapping注解，而使用@RequestMapping注解的方法才是真正处理请求的处理器
注意：这里注意@Controller 只是定义了一个控制器类，而使用@RequestMapping 注解的方法才是真正处理请求的处理器。单单使用@Controller 标记在一个类上还不能真正意义上的说它就是Spring MVC 的一个控制器类，因为这个时候Spring 还不认识它。那么要如何做Spring 才能认识它呢？这个时候就需要我们把这个控制器类交给Spring 来管理。
Spring MVC 是通过组件扫描机制查找应用中的控制器类的，为了保证控制器能够被 Spring MVC 扫描到，我们还需要在 Spring MVC 的配置文件中使用 <context:component-scan/> 标签，指定控制器类的基本包（请确保所有控制器类都在基本包及其子包下），示例代码如下。
<!-- 使用扫描机制扫描控制器类，控制器类都在net.biancheng.controller包及其子包下 --> <context:component-scan base-package="net.biancheng.controller" />
@RequestMapping 注解
RequestMapping是一个用来处理请求地址映射的注解，可用于类或方法上。
Spring MVC 的前端控制器（DispatcherServlet）拦截到用户发来的请求后，会通过 @RequestMapping 注解提供的映射信息找到对应的控制器方法，对这个请求进行处理。
@RequestMapping 注解的使用方式
@RequestMapping 既可以标注在控制器类上，也可以标注在控制器方法上。
1. 修饰方法
当 @RequestMapping 注解被标注在方法上时，value 属性值就表示访问该方法的 URL 地址。当用户发送过来的请求想要访问该 Controller 下的控制器方法时，请求路径就必须与这个 value 值相同，示例代码如下。
@Controller public class HelloController { @RequestMapping("/login") public String welcome() { return "login"; } }
2. 修饰类
当 @RequestMapping 注解标注在控制器类上时，value 属性的取值就是这个控制器类中的所有控制器方法 URL 地址的父路径。也就是说，访问这个 Controller 下的任意控制器方法都需要带上这个父路径。
@Controller @RequestMapping(value = "/springmvc") public class HelloController { @RequestMapping("/login") public String welcome() { return "login"; } }
例如，在上面的控制类中，用户想要访问 HelloController 中的 welcome() 方法，请求的地址就必须带上父路径“/springmvc”，即请求地址必须为“/springmvc/login”。
@RequestMapping 注解的属性
@RequestMapping 注解中提供了多个可用属性，下面我们就对其中几个比较常用的属性进行介绍。
1. value 属性
在 @RequestMapping 注解中，value 属性用来设置控制器方法的请求映射地址。所有能够匹配到该请求映射地址的请求，都可以被该控制器方法处理，示例代码如下。
@RequestMapping(value = "/register")
value 属性是 @RequestMapping 注解的默认属性，如果我们在 @RequestMapping 注解中只设置了一个 value 属性，则该属性名可以被省略，示例代码如下。
//省略 value 属性名 @RequestMapping( "/register")
2. name 属性
name 属性相当于方法的注释，用于解释这个方法是用来干什么的，使方法更易理解。
例如，下面的代码表示 getUsers() 方法是一个用来获取用户信息的控制器方法。
@RequestMapping(value = "toUser",name = "获取用户信息") public String getUsers() { …… }
3. method 属性
method 属性用来设置控制器方法支持的请求方式。如果一个控制器方法没有设置 @RequestMapping 注解的 method 属性，则说明该控制器方法支持全部请求类型，可以处理所有类型的请求。
method 属性的取值是一个 RequestMethod 类型的数组，表示一个控制器方法支持多种方式的请求，常用的请求方式有 GET、POST、DELETE、PUT 等。
例如，控制器方法只支持 GET 方式的请求，代码如下。
@RequestMapping(value ="/toUser",method = RequestMethod.GET)
我们也可以为同一个控制器方法指定支持多种类型的请求。例如，一个方法既支持 GET 方式的请求，也支持 POST 方式的请求，代码如下。
@RequestMapping(value = "/toUser",method = {RequestMethod.GET,RequestMethod.POST})
4. params 属性
params 属性用于指定请求中的参数，只有当请求中携带了符合条件的参数时，控制器方法才会对该请求进行处理。
我们可以通过以下 4 种表达式来对请求的参数进行配置。
params 属性的取值是一个字符串类型的数组，表示只有请求中同时携带了 params 属性指定的全部参数时，控制器方法才会对该请求进行处理。
例如，控制器方法 testParam() 的代码如下：
@RequestMapping(value = "/testParam", params = {"name=C语言中文网", "url=http://c.bianheng.net"}) @ResponseBody public String testParam() { return "success"; }
以上代码表示，只有当请求中同时携带 name 和 url 两个请求参数，且参数值必须分别为 “C语言中文网” 和“http://c.biancheng.net”时，控制器方法 testParam() 才会对该请求进行处理 。
5. headers 属性
headers 属性用于设置请求中请求头信息，只有当请求中携带指定的请求头信息时，控制器方法才会处理该请求。
我们可以通过以下 4 种表达式来指定请求中的请求头信息。
header 属性是一个字符换类型的数组，表示只有当请求同时携带数组中规定的所有头信息时，控制器方法才会对该请求进行处理。
例如，控制器方法 method() 的代码如下。
@RequestMapping(value = "toUser",headers = "Referer=http://c.biancheng.net") public String metnod() { …… }
在以上代码中，只有当请求的头信息中包含“Referer=http://c.biancheng.net”时，控制器方法 method() 才会处理该请求。
