什么是MVC？什么是SpringMVC？什么是三层架构？

在讲解什么是MVC之前，先来理解一下什么是应用分层。

应用分层是一种软件开发设计思想，将应用程序划分成N个层次，每个层次都分别负责自己的职责，多个层次之间来协同提供完整的功能，根据项目的复杂度，将项目分成三层或四层等。

举个例子：比如，一个公司创始初期，创始人要身兼数职，既要做财务，又要做人事，又要做行政，但随着公司的越来越大，就会划分成多个不同的部门。

为什么要进行应用分层？？？

在功能简单，代码量少是，我们通常不考虑分层，但是，随着业务越来越复杂，功能越来越强大，大量的代码都混在了一起，会出现逻辑不清晰，各模块相互依赖，代码扩展性差，改动一处牵动全身等问题，所以，就要对项目进行分层，MVC 和 三层架构 都是应用分层的充分体现，下面先看一下什么是MVC。

MVC(Model View Controller)，它是一种思想，他把软件系统分为 以下三部分：

Model(模型)：用来处理程序中数据逻辑的部分

View(视图)：在应用程序中，专门和浏览器进行交互，展示数据的资源

Contreller(控制器)：可以理解成是一个分发器，来决定对于视图发来的请求，需要用哪一个模型来处理，以及处理完后需要跳回到哪一个视图，也就是用来连接视图和模型的

举个例子：

1.比如进入京东的购物页面

2.搜索手机

以上的过程，当进入京东购物网站时，这个页面就相当于是一个视图，它向我们展示了各种各样的资源，在我们搜索手机这个资源时，就会发送出一个请求，此时，这个请求会交给 控制器(Controller)，控制器针对这个请求就会选择对应处理模型(Model)，对这个请求进行处理，而上图的展示的手机资源的页面，就相当于是处理模型处理的结果，由控制器再将这个视图返回给我们。

再举一个简单的例子：

比如我们去餐厅吃饭，服务员就会来接待我们，服务员就会将我们点的菜写在小本本上，然后交给前台，前台再交给厨师，厨师做完之后，就会再交给前台，前台再根据这个菜确定是哪个菜单，然后再让服务员交给客人，此时，服务员帮我们写菜单就相当于是一个视图，前台就相当于是控制器，厨师就相当于是模型

MVC 它是一种思想，而SpringMVC 它是将这种思想进行了实现，除此之外，SpringMVC 还是一种 Web 框架

比如，在创建 SpringBoot 项目时，所勾选的 Spring Web 框架就是SpringMVC框架，所以，可能就会产生这样的疑问：我们创建的不是SpringBoot项目吗，怎么变成了 SpringMVC 项目，它们俩之间到底有什么关系呢？？？

SpringBoot 和 SpringMVC 的关系

SpringBoot是2014年发布的,Spring是2004年发布的,在2014年发布之前,就不能⽤Spring实现MVC架构吗?当然不是了.

SpringBoot 只是实现 SpringMVC 的一种方式，SpringBoot 可以添加很多的依赖，借助这些依赖实现不同的功能，SpringBoot 就是通过添加 SpringWebMVC框架，来实现Web功能

举个例子：

比如做饭，我们做饭不是只能在厨房做，做饭这个事情在几千年就有了，只要有火有食材就可以做，所以做饭就比是 MVC，SpringBoot 就好比是厨房，通过在厨房里装燃气灶，装一些工具等，也可以实现做饭这个功能。

所以，如果想要实现 Web开发的话，就要引入这个 Web 框架

Spring在实现 MVC的时候，也做了一些改进：

直接把请求发给 控制器Controller，并不经过视图。就像我们去餐厅吃饭时，不需要服务员为我们记录菜单了，直接由前台记录，记录完之后交给厨师。

现在MVC这种方式也已经不再使用了，而主流的是前后端分离，不再需要View这个模块了，不需要再关注于前端了，我们只要约定好接口，写好后端即可，所以，对于后端，也有了一种新的分层方式，就是三层架构，分为以下三层：

按照这样的层次划分，Spring MVC 站在后端的角度上，就将代码分成了：

从概念上来讲，两者都是软件工程中的架构模式，并且两者也是非常相似的，就如下面这张图：

三层架构的“表现层”也就是对应着MVC的 View层 和 Ctroller层，因为它们都是用来展示数据和接收请求的，所以，站在后端人员的角度上看，其实， 表现层也可以看成是视图层，三层架构中的业务逻辑层和数据层对应的就是MVC中的model层，都是用来处理业务逻辑的。二者只不过是从不同角度上进行了抽象，MVC它强调的是数据和视图的分离，将数据的展示和数据的处理分开。通过控制器对两者进行结合。三层架构强调的是从不同纬度上对数据进行处理，以达到“高内聚，低耦合”

高内聚：一个模块中各个元素之间的联系的紧密程度，如果各个元素之间的联系程度越高，则内聚性越高，即“高内聚”。

低耦合：项目中，各个层或者模块间的依赖关联程度越低越好，不会因为修改一处代码，造成很多的代码都需要改动。