MVC和三层架构思考

文章说明：本文为作者个人学习过程中的感悟和理解，如有不正确的地方，恳请各位指正。学习参考的链接如下：
MVC与三层架构

在校学习时，常听老师说MVC架构和软件开发的三层架构，一直也没有深入理解过，认为他们都是三层就将他们臆想为同一事物。现在有时间可以静心仔细思考，力求弄清楚其本质。

先来看看MVC和三层架构长啥样

MVC架构

先来学习一下什么是MVC：
MVC的组成，：model（模型）、view（视图）、controller（控制器），这是一个老掉牙的问题，那么具体含义是什么呢。

view:视图，即我们看到的页面，一般使用html或者jsp写出
model:模型，我们知道其实软件的本质就是对数据的处理，模型就是各种 数据 和 处理逻辑。具体到Java这
种纯面向对象的语言中，模型就是  数据承载Bean和业务处理Bean，所谓数据承载Bean是指实体类，专门承
载业务数据的，如Student、User等。而业务处理Bean则是指Service或Dao对象，用来处理数据和操作数
据库。
controller:控制器，我把他看作程序的指向标，它接收前端的请求，将其转给相应的model，并将model处理完得到的数据返回给前端展示给用户。（控制器只是一个指向标，数据处理的代码应尽量不出现在其中）。

MVC架构的工作流程为：
（1）用户操作 View页面 向 服务端 提出请求并传送数据，例如表单请求、超链接请求、AJAX请求等。
（2）服务端Controller控制器根据请求，调用相关的 Model 处理数据。
（3）Model处理后，将处理结果再交给Controller。
（4）Controller控制器根据处理结果找到要返回给客户端的View页面，并将数据填充到页面中，然后将页面发送给客户端展示。

放一位不知名前辈的图：

三层架构

三层架构的组成包括：视图层View、服务层Service、持久层Dao。各层的功能如下：

View：用户看到的页面和接收用户请求
Service：进行数据处理的逻辑代码
Dao：对数据库进行操作

为了更好的降低各层间的耦合度，在三层架构程序设计中，采用面向抽象编程。即上层对下层的调用，是通过接口实现的。而下层对上层的真正服务提供者，是下层接口的实现类。服务标准（接口）是相同的，服务提供者（实现类）可以更换。这就实现了层间的耦合。
还是看一下这位大佬的图：

重点来了，下面来看一下MVC架构和三层架构的关系

MVC和三层架构关系推敲

先总结一下大佬的想法，这也是网上绝大部分前辈认同的观点：
三层架构中的View层 相当于 MVC中的V和C，它们与用户发生直接交互，即 可以被用户操作或接收用户的请求
MVC中的M包括数据承载Bean和业务处理Bean，而业务处理Bean分为Service或Dao对象，分别对应业务逻辑处理和数据库操作，它们 相当于 三层架构中的Service层和Dao层

综上，我想提出这样一种架构发展的猜想：

为了降低系统模块间的耦合度，前人们提出了MVC架构，将软件从系统层面抽象出 M，V 和 C三部分，即任何一个软件系统都可以看作由 页面、功能实现和控制中心组成。

举个栗子🌰，我们把软件系统想象成一家餐馆，其包括 菜单（即视图V）、店员（即控制器C)和做川鲁粤菜的厨房（即模型M），客人根据菜单（页面）
展示的内容决定要吃点什么（发出什么请求），然后反馈给店员（控制器），店员根据客人点的菜（请求）报给合适的厨房，菜做好之后店员再将其送到
相应的客户桌上。

其实从上面例子我们不难看出，餐馆中真正完成客户需求的是厨房，即软件MVC架构中真正为客户提供服务的是M模型中的业务处理逻辑，这也就是一个软件系统最复杂的地方，里面有着解决各种问题的方法，如此复杂的部分和逻辑非常简单的页面、控制器竟然相提并论，这貌似有些不合理。简单来说，MVC架构并没有将软件系统中最复杂的部分划分开，只是将整个软件系统从整体上简单划分了一下

基于上述问题，前人们决定将软件系统中最复杂的M模型部分进一步划分成Service层和Dao层，然后将逻辑简单的控制器与页面合并，共同成为View页面层，三层架构也就应运而生。

当然，以上猜想只是我个人根据对两种架构的理解提出的，并没有历史性的依据，但是至少，也许可以帮我们更好地理解两种架构。

说白了，三层架构和MVC架构，其本质上是一样的，但是其分层并不是简单的一一对应。综合这两种架构的划分思路，就有了当下大部分软件的四层划分，即 页面层，控制层（Controller），逻辑处理/服务层（Service）和 数据库操作层（Dao），基于此，如果某一层仍然比较复杂，我们甚至可以再对某一层进行划分。