MVC概述
MVC模式就是架构模式的一种，Model（模型）、View（视图）和Controller（控制）组成，MVC结构可以分成三层：
- 最上面的一层，是直接面向最终用户的视图层View。它是提供给用户的操作界面，是程序的外壳
- 最底下的一层，是核心的数据层Model，也就是程序需要操作的数据或信息
- 中间的一层，是控制层Controller，它负责根据用户从视图层输入的指令，选取数据层中的数据，然后对其进行相应的操作，产生最终结果
这三层是紧密联系在一起的，但又是互相独立的，每一层内部的变化不影响其他层。每一层都对外提供接口，供上面一层调用，实现模块化。
MVC和MVP
MVP，Model负责数据处理；View负责呈现界面；Presenter负责业务功能，将Model层的数据安全送往View层。Model和View是不能互通的，需要经过中间的Presenter进行传递，这一点不同于MVC模式。MVC模式中View可以直接获取并操作数据，造成View层对数据层的关联。
相比于MVC模式，MVP模式具有更加严格的分层和清晰的结构，这种分层方式更能保证各个层次尽量少的依赖。从MVP的架构来看，Model层逻辑具有高独立性，但Model层需要依赖数据、网络、设备等外部因素。Presenter层依赖于Model和View，而View层依赖于Presenter层和设备。
技巧
Controller
在开发MVC应用时，第一步便是编写Controller，方法有4种：
- 使用Spring MVC提供的针对特定目的而设计的控制器类（不常用）：
- AbstractUrlViewController
- MultiActionController
- ParameterizableViewController
- ServletForwardingController
- ServletWrappingController
- UrlFilenameViewController
- 使用注解@Controller配置（代码略）
- 实现Controller接口并重写
handleRequest()方法：
public class DemoController implements Controller {
@Override
public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {
return new ModelAndView("main");
}
}
同时需要添加配置：<bean name="/main" class="aa.bb.DemoController"/>
- 若要控制受支持的HTTP方法，会话和内容缓存，还可以继承AbstractController并重写方法handleRequestInternal：
public class BigController extends AbstractController {
@Override
protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) throws Exception {
return new ModelAndView("big");
}
}
同时配置：
<bean name="/big" >
<property name="supportedMethods" value="POST"/>
</bean>
@RequestMapping
@RequestMapping可用于指定一个方法要处理的多个URL模式：
@RequestMapping({"/hello", "/hi", "/greetings"})
@RequestMapping可以指定RequestMethod，如RequestMethod.GET；此时可用@GetMapping代替，即等价于@RequestMapping(method = {RequestMethod.GET})
RequestParam
ModelAndView和ModelMap
ModelAndView对象有两个作用：
- 设置转向地址
ModelAndView view = new ModelAndView("path:ok"); - 用于传递控制方法处理结果数据到结果页面，也就是说把需要在结果页面上展示的数据放到ModelAndView对象中即可，作用类似于request对象的setAttribute方法的作用，用来在一个请求过程中传递处理的数据。通过以下方法向页面传递参数：
addObject(String key,Object value); 在页面上可以通过el变量方式$key或者bboss的一系列数据展示标签获取并展示ModelAndView中的数据。
Model 是一个接口， 其实现类为ExtendedModelMap，继承ModelMap类。
ModelMap对象主要用于传递控制方法处理数据到结果页面，也就是说把结果页面上需要的数据放到ModelMap对象中即可，作用类似于request对象的setAttribute方法的作用，用来在一个请求过程中传递处理的数据。通过以下方法向页面传递参数：
addAttribute(String key,Object value); 在页面上可以通过el变量方式$key或者bboss的一系列数据展示标签获取并展示modelmap中的数据。
ModelMap本身不能设置页面跳转的url地址别名或者物理跳转地址，可以通过控制器方法的返回值来设置跳转url地址别名或者物理跳转地址。
ModelMap的实例是由Spring mvc框架自动创建并作为控制器方法参数传入，用户无需自己创建。
两者区别
- ModelAndView可以设置转向地址
- ModelAndView的实例是由用户手动创建的
Spring的控制器Controller会返回一个ModelAndView的实例，包括View和Model信息，视图是以名字为标识的，ViewResolver是通过名字来解析view的。
如果方法添加注解@ResponseBody ，则会直接将返回值输出到页面。
ViewResolver，视图解析器，提供从视图名称到实际视图的映射。
文件上传
@RequestMapping(value = "/uploadFiles", method = RequestMethod.POST)
public String fileUpload(@RequestParam CommonsMultipartFile[] fileUpload) throws Exception {
for (CommonsMultipartFile item : fileUpload){
// 存储上传的文件
item.transferTo(new File(item.getOriginalFilename()));
}
return "Success";
}
通过自动将上传数据绑定到CommonsMultipartFile对象数组，默认使用Apache Commons FileUpload作为文件解析器。
文件下载
HttpServletRequest和HttpServletResponse
示例代码：
@RequestMapping("/download")
public String doDownloadFile(HttpServletRequest request, HttpServletResponse response) {
// 访问请求/响应
return "";
}
Spring检测并自动将HttpServletRequest和HttpServletResponse对象注入方法中。
WebFlux & Spring MVC
WebFlux不是Spring MVC的替代方案，WebFlux 也可以运行在Servlet容器上（Servlet 3.1+），WebFlux主要还是应用在异步非阻塞编程模型，而 Spring MVC 是同步阻塞的。两者可以混合使用。
函数式编程
异常处理
如果没有统一异常处理，或需要做个性化的异常处理，实例：
/**
* 接口附带异常处理逻辑.
*
* @param userService the user service
* @return the user by name with error handle
*/
public RouterFunction<ServerResponse> withErrorHandle() {
return RouterFunctions.route()
.GET("/userwitherrorhandle/{username}",
request -> ServerResponse.ok()
.body(userService.getByName(request.pathVariable("username"))))
// 异常处理
.onError(RuntimeException.class,
(e, request) -> EntityResponse.fromObject(e.getMessage())
.status(HttpStatus.INTERNAL_SERVER_ERROR)
.build())
.build();
}
onError 方法及其重载方法进行接口的异常处理。
过滤器
通过 filter 方法可以实现日志、安全策略、跨域等功能：
/**
* 对特定接口指定过滤器.
*
* @param userService the user service
* @return the router function
*/
public RouterFunction<ServerResponse> withFilter() {
return RouterFunctions.route().POST("/save",
request -> ServerResponse.ok()
.body(userService.saveUser(request.body(UserInfo.class))))
// 执行过滤器逻辑 参数携带 save 放行 否则返回 bad request 并附带消息
.filter((request, next) -> request.param("save").isPresent() ?
next.handle(request) :
ServerResponse.status(HttpStatus.BAD_REQUEST).body("no save"))
.build();
}
拦截器
提供类似过滤器前置/后置处理机制，before 和 after 方法将分别进行前置和后置处理，可达到相同效果：
public RouterFunction<ServerResponse> getUserByName() {
return RouterFunctions.route()
.GET("/user/{username}",
request -> ServerResponse.ok()
.body(userService.getByName(request.pathVariable("username"))))
// 前置处理 打印 path
.before(serverRequest -> {
(serverRequest.path());
return serverRequest;
})
// 后置处理 如果响应状态为200 则打印 response ok
.after(((serverRequest, serverResponse) -> {
if (serverResponse.statusCode() == HttpStatus.OK) {
("response ok");
}
return serverResponse;
})).build();
}
统一处理
@Bean
RouterFunction<ServerResponse> userEndpoints(UserController userController) {
return RouterFunctions.route()
.path("/v2/user", builder -> builder
.add(userController.getUserByName()
.and(userController.delUser()
.and(userController.saveUser()
.and(userController.updateUser())))))
.build();
}
@Bean
RouterFunction<ServerResponse> nestEndpoints(UserController userController) {
return RouterFunctions.route().nest(RequestPredicates.path("/v1/user"),
builder -> builder
.add(userController.getUserByName())
.add(userController.delUser())
.add(userController.saveUser())
.add(userController.updateUser()))
// 对上述路由进行统一异常处理
.onError(RuntimeException.class,
(throwable, serverRequest) -> ServerResponse
.status(HttpStatus.BAD_REQUEST)
.body("bad req"))
.build();
}
进阶
web.xml中listener、filter和servlet的初始化顺序
顺序：listener -> filter -> servlet 对使用<listener>标签声明的监听器类进行实例化，调用监听器类实例对象的contextInitialized()方法，初始化应用上下文数据；其次对使用<filter>标签声明的过滤器类进行实例化，调用过滤器类实例对象的init()方法；如果<servlet>标签内使用<load-on-startup>标签，则按照数值从小到大的顺序对Servlet进行实例化，并调用对应的init()方法。
applicationContext.xml如何自动加载
当运行一个Web项目时，应用服务器(如Tomcat)首先会读取项目源码路径中的web.xml文件，解析其中的配置，发现配置ContextLoaderListener，因此会执行ContextLoaderListener类中的contextInitialized方法，在这个方法中会调用initWebApplicationContext()方法，用于初始化一个WebApplicationContext，即初始化一个Web应用下的Spring容器。在initWebApplicationContext()方法后续代码实现的内部会根据web.xml中配置的contextConfigLocation属性加载指定的applicationContext.xml文件，根据这个文件初始化Spring容器。若没配置contextConfigLocation参数，那么应用启动时会默认查找应用根目录下/WEB-INF/applicationContext.xml文件，也就是说这是一个默认加载的文件路径
DispatcherServlet
SpringMVC的核心分发器，实现请求分发，是处理请求的入口。DispatcherServlet是一个Servlet，在应用启动时，DispatcherServlet初始化会执行init方法，DispatcherServlet的init方法继承自HttpServletBean，在这个初始化方法中会实例化一个WebApplicationContext对象，并且将初始化后的context存到ServletContext中，让Servlet和Spring容器进行关联。在DispatcherServlet的onRefresh方法中，初始化各种请求处理策略，如文件上传处理策略、URL请求处理策略、视图映射处理策略、异常处理策略等，这些策略的大部分执行逻辑都是先从WebApplicationContext中查找，找不到的情况下再加载和DispatcherServlet同目录下的DispatcherServlet.properties中的各个策略，例如初始化HandlerMapping，注册各种请求的处理策略及处理类。
SpringMVC框架在启动的时候会遍历Spring容器中的所有bean，对标注@Controller或@RequestMapping注解的类中方法进行遍历，将类和方法上的@RequestMapping注解值进行合并，使用@RequestMapping注解的相关参数值(如value、method等)封装一个RequestMappingInfo，将这个Controller实例、方法及方法参数信息(类型、注解等)封装到HandlerMethod中，然后以RequestMappingInfo为key，HandlerMethod为value存到一个以Map为结构的handlerMethods中。
接着将@RequestMapping注解中的value(即请求路径)值取出，即url，然后以url为key，以RequestMappingInfo为value，存到一个以Map为结构的urlMap属性中。
客户端发起请求时，根据请求的URL到urlMap中查找，找到RequestMappingInfo，然后根据RequestMappingInfo到handlerMethods中查找，找到对应的HandlerMethod，接着将HandlerMethod封装到HandlerExecutionChain；接着遍历容器中所有HandlerAdapter实现类，找到支持这次请求的HandlerAdapter，如RequestMappingHandlerAdapter，然后执行SpringMVC拦截器的前置方法(preHandle方法)，然后对请求参数解析及转换，然后(使用反射)调用具体Controller的对应方法返回一个ModelAndView对象，执行拦截器的后置方法(postHandle方法)，然后对返回的结果进行处理，最后执行afterCompletion方法。
