Spring MVC基础
# 基础
谈到这个问题，我们不得不提提之前 Model1 和 Model2 这两个没有 Spring MVC 的时代。
Model1 时代 : 很多学 Java 后端比较晚的朋友可能并没有接触过 Model1 模式下的 JavaWeb 应用开发。在 Model1 模式下，整个 Web 应用几乎全部用 JSP 页面组成，只用少量的 JavaBean 来处理数据库连接、访问等操作。这个模式下 JSP 即是控制层又是表现层。显而易见，这种模式存在很多问题。比如①将控制逻辑和表现逻辑混杂在一起，导致代码重用率极低；②前端和后端相互依赖，难以进行测试并且开发效率极低；
Model2 时代 ：学过 Servlet 并做过相关 Demo 的朋友应该了解“Java Bean(Model)+ JSP（View,）+Servlet（Controller） ”这种开发模式，这就是早期的 JavaWeb MVC 开发模式。Model：系统涉及的数据，也就是 dao 和 bean**。View：展示模型中的数据，只是用来展示。Controller：处理用户请求都发送给 ，返回数据给 JSP 并展示给用户**。
Model2 模式下还存在很多问题，Model2的抽象和封装程度还远远不够，使用Model2进行开发时不可避免地会重复造轮子，这就大大降低了程序的可维护性和复用性。于是很多JavaWeb开发相关的 MVC 框架应运而生比如Struts2，但是 Struts2 比较笨重。随着 Spring 轻量级开发框架的流行，Spring 生态圈出现了 Spring MVC 框架， Spring MVC 是当前最优秀的 MVC 框架。相比于 Struts2 ， Spring MVC 使用更加简单和方便，开发效率更高，并且 Spring MVC 运行速度更快。
MVC 是一种设计模式，Spring MVC 是一款很优秀的 MVC 框架。Spring MVC 可以帮助我们进行更简洁的Web层的开发，并且它天生与 Spring 框架集成。Spring MVC 下我们一般把后端项目分为 Service层（处理业务）、Dao层（数据库操作）、Entity层（实体类）、Controller层(控制层，返回数据给前台页面)。
# Spring MVC 总览
Spring MVC是Spring提供的一个强大而灵活的Web框架，它是一款实现了MVC设计模式的、请求驱动的轻量级Web框架。**Spring MVC使用MVC架构模式将Web层的各组件进行了解耦。**借助Spring提供的注解功能，Spring MVC提供了POJO（Plain Ordinary Java Object）的开发模式，使得开发和测试更加简单，开发效率更高。
流程说明（重要）：
- 客户端（浏览器）发送请求，直接请求到 DispatcherServlet。
- DispatcherServlet 根据请求信息调用 HandlerMapping，解析请求对应的 Handler。
- 解析到对应的 Handler（也就是我们平常说的 Controller 控制器）后，开始由 HandlerAdapter 适配器处理。
- HandlerAdapter 会根据 Handler 来调用真正的处理器开处理请求，并处理相应的业务逻辑。
- 处理器处理完业务后，会返回一个 ModelAndView 对象，Model 是返回的数据对象，View 是个逻辑上的 View。
- ViewResolver 会根据逻辑 View 查找实际的 View。
- DispaterServlet 把返回的 Model 传给 View（视图渲染）。
- 把 View 返回给请求者（浏览器）
# Spring MVC 与三层架构
MVC： model + view + controller
三层架构： 展现层（view） + 应用层（service） + 数据访问层（dao）
# 三层架构
三层架构是指：视图层View、服务层Service、持久层Dao，分别完成不同的功能。
View层：用于接收用户提交请求的代码在这里编写。
Service层：系统的业务逻辑主要在这里编写。
Dao层：直接操作数据库的代码在这里编写。
为了更好的降低各层间的耦合度，在三层架构程序设计中，采用面向抽象编程。即上层对下层的调用，是通过接口实现的。而下层对上层的真正服务提供者，是下层接口的实现类。服务标准（接口）是相同的，服务提供者（实现类）可以更换。这就实现了层间的耦合。
# MVC
MVC是指：Model模型、View视图、Controller控件器。
View：视图，为用户提供使用界面，与用户直接进行交互。
Model：模型，承载数据，并对用户提交请求进行计算的模块。其分为两类，一类称为数据承载Bean，一类称为业务处理Bean。所谓数据承载Bean是指实体类，专门承载业务数据的，如Student、User等。而业务处理Bean则是指Service或Dao对象，专门用于处理用户提交请求的。
Controller：控制器，用于将用户请求转发给相应的Model进行处理，并处理Model的计算结果向用户提供相应响应。
MVC架构程序的工作流程是这样的：
（1）用户通过View页面向服务端提出请求，可以是表单请求、超链接请求、AJAX请求等。
（2）服务端Controller控制器接收到请求后对请求进行解析，找到相应 的Model对用户请求进行处理。
（3）Model处理后，将处理结果再交给Controller。
（4）Controller在接到处理结果后，根据处理结果找到要作为向客户端发回的响应View页面。页面经渲染（数据填充）后，再发送给客户端。
# MVC与三层架构的关系
model并不等于数据访问层，view也不等于展现层，controller更不代表应用层。
实际上MVC只存在三层架构的展现层
MVC与三层架构很相似，但它们并不一样。如果以三层架构为背景，那么MVC的三个部分分别对应的是什么？
三层架构中的View层简单的说就是跟用户发生直接关系的层，MVC中的V和C就是这样的存在，所以MVC中的V和C均属于三层架构的View层。同时，我们知道MVC中的M（Model）包括了数据承载Bean和业务处理Bean，其中业务处理Bean分为Service或Dao对象，分别对应业务逻辑处理和数据库操作，相应的，它们对应的是三层架构中的Service层和Dao层。
故，它们的关系如下图所示：
# SSM与三层架构的关系
SSM即SpringMVC、Spring、Mybatis三个框架。它们在三层架构中所处的位置是不同的，即它们在三层架构中的功能各不相同，各司其职。
SpringMVC：作为View层的实现者，完成用户的请求接收功能。SpringMVC的Controller作为整个应用的控制器，完成用户请求的转发及对用户的响应。
MyBatis：作为 Dao层的实现者，完成对数据库的增、删、改、查功能。
Spring：以整个应用大管家的身份出现。整个应用中所有的Bean的生命周期行为，均由Spring来管理。即整个应用中所有对象的创建、初始化、销毁，及对象间关联关系的维护，均由Spring进行管理。
# Spring MVC常用注解
@Controller, @RequestMapping, @ResponseBody, @RequestBody, @RestController, @PathVariable
# @Controller和@RestController区别
- @RestController 是一个组合注解， 组合了@Controller和@ResponseBody
- Controller 返回一个页面**。**单独使用 @Controller 不加 @ResponseBody的话一般使用在要返回一个视图的情况，这种情况属于比较传统的Spring MVC 的应用，对应于前后端不分离的情况。
- @RestController **返回JSON 或 XML 形式数据。**但@RestController只返回对象，对象数据直接以 JSON 或 XML 形式写入 HTTP 响应(Response)中，这种情况属于 RESTful Web服务，这也是目前日常开发所接触的最常用的情况（前后端分离）。
@Controller +@ResponseBody 返回JSON 或 XML 形式数据
@ResponseBody 注解的作用是将 Controller 的方法返回的对象通过适当的转换器转换为指定的格式之后，写入到HTTP 响应(Response)对象的 body 中，通常用来返回 JSON 或者 XML 数据，返回 JSON 数据的情况比较多。
# Spring MVC拦截器
- 可让普通的Bean实现HanlderInterceptor接口或者继承HandlerInterceptorAdapter类来实现自定义拦截器。
- 重写preHandle方法，在请求发生前执行。重写postHandle方法，在请求完成后执行。
- 配置拦截器的Bean。重写addInterceptors方法，注册拦截器。
# BO，entity，VO，PO的区别？
# RestFul规范
RESTful是目前最流行的API设计规范，它是用于Web数据接口的设计。从字面可以看出，他是Rest式的接口，所以我们先了解下什么是Rest。
REST与技术无关，它代表的是一种软件架构风格，REST它是 Representational State Transfer的简称，中文的含义是: "表征状态转移" 或 "表现层状态转化"。它是基于HTTP、URI、XML、JSON等标准和协议，支持轻量级、跨平台、跨语言的架构设计。
# 一. 理解为什么要使用RESTful API设计规范？
在很久以前，工作时间长的同学肯定经历过使用velocity语法来编写html模板代码，也就是说我们的前端页面放在服务器端那边进行编译的，更准确的可以理解为 "前后端没有进行分离"，那么在那个时候，页面、数据及模板渲染操作都是放在服务器端进行的，但是这样做有一个很大的缺点是: 后期维护比较麻烦，前端开发人员还必须掌握velocity相关的语法。因此为了解决这个问题慢慢就出现了前后端分离的思想: 即后端负责数据接口, 前端负责数据渲染, 前端只需要请求下api接口拿到数据，然后再将数据显示出来。因此后端开发人员需要设计api接口，因此为了统一规范: 社区就出现了 RESTful API 规范，其实该规范很早就有的，只是最近慢慢流行起来，RESTful API 可以通过一套统一的接口为所有web相关提供服务，实现前后端分离。
# 二. Rest设计原则
那么怎么样可以设计成REST的架构规范呢? 需要符合如下的一些原则：
- 每一个URI代表一种资源;
- 同一种资源有多种表现形式(xml/json);
- 所有的操作都是无状态的。
- 规范统一接口。
- 返回一致的数据格式。
- 可缓存(客户端可以缓存响应的内容)。
符合上述REST原则的架构方式被称作为 RESTful 规范。