SpringMVC与三层架构

一、SpringMVC

1.1 概述

MVC 是模型(Model)、视图(View)、控制器(Controller)的简写，其核心思想是通过将业务逻辑、数据、显示分离来组织代码。

MVC 是一种使用 MVC（Model View Controller 模型-视图-控制器）设计创建 Web 应用程序的模式：

• View： 视图，为用户提供使用界面，与用户进行交互。
• Model： 模型承载数据，对用户提交请求进行计算的模块，分为两类：
  • 数据承载bean，数据承载bean是指实体类专门承载业务数据的，比如Student，User。
  • 业务承载bean，业务处理bean是指Service或者Dao对象，专门处理用户的请求的。
• Controller：控制器，用来将用户请求转发给相应的Model进行处理，并且根据Model的计算结果向用户提供相应的响应。

想要真正理解 Spring MVC，我们先来看看 Model 1 和 Model 2 这两个没有 Spring MVC 的时代。
Model 1 时代
很多学 Java 后端比较晚的朋友可能并没有接触过 Model 1 时代下的 JavaWeb 应用开发。在 Model1 模式下，整个 Web 应用几乎全部用 JSP 页面组成，只用少量的 JavaBean 来处理数据库连接、访问等操作。这个模式下 JSP 即是控制层（Controller）又是表现层（View）。显而易见，这种模式存在很多问题。比如控制逻辑和表现逻辑混杂在一起，导致代码重用率极低；再比如前端和后端相互依赖，难以进行测试维护并且开发效率极低。

Model 2 时代
学过 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 MVC 时代
随着 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 层(控制层，返回数据给前台页面)。

1.2 SpringMVC核心组件

• DispatcherServlet：核心的中央处理器，负责接收请求、分发，并给予客户端响应。
• HandlerMapping：处理器映射器，根据 uril去匹配查找能处理的 Handler ，并会将请求涉及到的拦截器和 Handler 一起封装。
• HandlerAdapter：处理器适配器，根据 HandlerMapping 找到的 Handler ，适配执行对应的 Handler；
• Handler：请求处理器，处理实际请求的处理器。
• ViewResolver：视图解析器，根据 Handler 返回的逻辑视图 / 视图，解析并渲染真正的视图，并传递给 DispatcherServlet 响应客户端

1.3 SpringMVC工作原理

Spring MVC 工作流程：

Spring MVC 原理如下图所示：

流程说明：

• 客户端（浏览器）发送请求， DispatcherServlet拦截请求。
• DispatcherServlet 根据请求信息调用 HandlerMapping 。
• HandlerMapping 根据 url 去匹配查找能处理的 Handler（也就是我们平常说的 Controller 控制器） ，并会将请求涉及到的拦截器和 Handler 一起封装。
• DispatcherServlet 调用 HandlerAdapter适配器执行 Handler 。
• Handler 完成对用户请求的处理后，会返回一个 ModelAndView 对象给DispatcherServlet，ModelAndView 顾名思义，包含了数据模型以及相应的视图的信息。Model 是返回的数据对象，View 是个逻辑上的 View。
• ViewResolver 会根据逻辑 View 查找实际的 View。
• DispaterServlet 把返回的 Model 传给 View（视图渲染）。
• 把 View 返回给请求者（浏览器）

1.4 统一异常处理

推荐使用注解的方式统一异常处理，具体会使用到 @ControllerAdvice + @ExceptionHandler 这两个注解 。

@ControllerAdvice
@ResponseBody
public class GlobalExceptionHandler {
    @ExceptionHandler(BaseException.class)
    public ResponseEntity<?> handleAppException(BaseException ex, HttpServletRequest request) {
      //......
    }

    @ExceptionHandler(value = ResourceNotFoundException.class)
    public ResponseEntity<ErrorReponse> handleResourceNotFoundException(ResourceNotFoundException ex, HttpServletRequest request) {
      //......
    }
}

这种异常处理方式下，会给所有或者指定的 Controller 织入异常处理的逻辑（AOP），当 Controller 中的方法抛出异常的时候，由被@ExceptionHandler 注解修饰的方法进行处理。

ExceptionHandlerMethodResolver 中 getMappedMethod 方法决定了异常具体被哪个被 @ExceptionHandler 注解修饰的方法处理异常。

@Nullable
	private Method getMappedMethod(Class<? extends Throwable> exceptionType) {
		List<Class<? extends Throwable>> matches = new ArrayList<>();
    //找到可以处理的所有异常信息。mappedMethods 中存放了异常和处理异常的方法的对应关系
		for (Class<? extends Throwable> mappedException : this.mappedMethods.keySet()) {
			if (mappedException.isAssignableFrom(exceptionType)) {
				matches.add(mappedException);
			}
		}
    // 不为空说明有方法处理异常
		if (!matches.isEmpty()) {
      // 按照匹配程度从小到大排序
			matches.sort(new ExceptionDepthComparator(exceptionType));
      // 返回处理异常的方法
			return this.mappedMethods.get(matches.get(0));
		}
		else {
			return null;
		}
	}

从源代码看出：getMappedMethod()会首先找到可以匹配处理异常的所有方法信息，然后对其进行从小到大的排序，最后取最小的那一个匹配的方法(即匹配度最高的那个)。

二、三层架构

三层架构是指：视图层view，服务层service，持久层Dao，通常也叫（表示层UI，业务逻辑层BLL，数据访问层DAL）它们的功能是：

• view层： 用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面
• service层：实现业务的主要逻辑，是系统架构中体现核心价值的部分。
• Dao层：有时候也称为是持久层，其功能主要是负责数据库的访问。可以访问数据库、二进制文件、文本文件等。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。

三层架构的出现是为了降低耦合度，在这里，使用面向抽象编程，也就是上层对下层的调用，直接通过接口来完成，下层对上层的真正服务提供者是下层实现的接口实现类，实现类是可以更换的，这就实现了层间的解耦合。

实际项目中的包命名结构，其实就是三层架构的体现：

xxx:代表公司名称	yyy：代表项目名称
com.xxx.yyy.dao	dao层接口
com.xxx.yyy.dao.impl	dao层实现
com.xxx.yyy.service	service层接口
com.xxx.yyy.service.impl	service层实现
com.xxx.yyy.web	web层
com.xxx.yyy.util	工具包
com.xxx.yyy.domain	javabean

三、MVC与三层架构

3.1 三层架构与MVC的关系

三层架构与MVC毫无关系。 之所以这样说，是因为它们二者使用范围不同：三层可以应用于任何语言、任何技术的应用程序；而MVC只是为了解决B-S应用程序视图层各部分的耦合关系。它们互不冲突，可以同时存在，也可根据情况使用其中一种。之所以我们会混淆，是因为在进行web开发时两者会同时使用。

在三层架构设计中，表示层可由MVC设计模式中的视图和控制器来实现，而业务逻辑层和数据访问层则组成MVC设计模式中的模型的实现。因此，在实际的应用中，都是采用三层架构来搭建系统的框架，而表示层与业务逻辑层和数据访问层的交互则是通过MVC设计模式来实现。

3.2 SSM与三层架构的对应关系

SSM，即Spring、SpringMVC与Mybatis的统称。

• Spring：是整个应用的大管家，整个应用中所有的bean的生命周期行为，都是由Spring来管理的，就是说整个应用中所有的对象的创建，初始化，销毁，以及对象之间关联的关系维护，都是由Spring来进行管理。
• SpringMVC：作为view的实现者，它的controller作为整个应用的控制器，完成用户请求的转发和对用户的响应。
• Mybatis：作为Dao的实现者，完成数据库的增删改查等功能。