应用分层、三层架构和MVC架构

前言

在前面中，我们已经学习了Spring MVC 的一些基础操作，那么后面就用一些简单的案例来巩固一下。

在开始学习做案例之前，我们先来了解一下在软件开发中常见的设计模式和架构。

应用分层

含义

应用分层是一种软件开发设计思想，将应用程序分成N个层次，每个层次各司其职，多个层次之间协同提供完整的功能。根据项目的复杂度，可以把项目分为三层、四层或者更多层。

我们前面学习的MVC设计模式，就是应用分层的一种具体体现。

为什么需要应用分层？

在早期项目开发的过程中，为了让项目快速上线，我们通常是不考虑分层的，但是随着业务越来越复杂，大量的代码堆积在一起，会出现逻辑不清晰、各模块相互依赖、可维护性、扩展性差，改动一处就可能牵动所有的问题。所以为了解决这些问题，我们就需要学习应用分层。

如何分层（三层架构）？

我们前面学习的MVC架构设计模式，是一种标准的软件分层架构，把整体的系统划分成了三个模块：View(视图)、Controller(控制器)、Model(模块)，也就是将用户视图和业务处理隔离开，并通过控制器来连接视图和模块，实现了表现和逻辑的解耦。

但其实现在我们更主流的开发方式是：前后端分离

后端不需要关注前端是如何实现的，只需要提供对应的接口即可，所以，对于我们java后端开发者，又多了一种新的分层架构：三层架构。 

三层架构

把整体架构分成表现层、业务逻辑层和数据层，这种分层方式称为“三层架构”。

每层功能

1. 表现层：负责展示数据结果和接收用户指令，是最接近用户的一层（负责接收页面的请求，给页面响应数据）；
2. 业务逻辑层：负责处理业务逻辑，里面负责业务逻辑的具体实现（负责业务逻辑处理的代码）；
3. 数据层：负责存储和管理与应用程序相关的数据（负责业务数据的维护操作，如CRUD）。

三层架构其实在Spring中也有实现：

1. 控制层(Controller)：负责结构前端发送的请求，对请求进行处理，并返回响应；
2. 业务逻辑层(Service)：负责具体的业务处理逻辑。
3. 数据访问层(Dao)：也称为持久层。负责数据访问操作，包括数据的CRUD。

MVC和三层架构区别和联系

区别：

MVC 架构模式是由三部分组成的，分别是：Model(模型)、视图(View)、控制器(Controller）。

三层架构将业务应用划分为：表现层、业务逻辑层、数据访问层。

从图中可以看到，MVC中，视图和控制器合起来对应三层架构中的表现层，模型对应三层架构中的业务逻辑层、数据层以及实体类。

联系：

• MVC和三层架构都是两种常见的软件设计模式和架构风格。
• 二者都是从不同角度对软件工程进行抽象。
• MVC强调将数据和视图分离，将数据展示和结果处理分开，通过控制器来对二者进行交互。
• 三层架构强调不同维度数据处理的高内聚、低耦合，将交互界面，业务处理和数据库操作的逻辑分开。二者强调的角度不同，也就谈不上互相替代了。但在日常开发中我们经常可以看到二者并存，比如，模型层（Model）我们会拆分出业务逻辑层（Service）和数据访问层（Dao）。
• 二者目的都是“解耦、分层、代码复用”。

什么是高内聚低耦合？

高内聚低耦合是一种软件设计原则。

高内聚指一个模块中各个元素之间的联系的紧密程度，如果各个元素(语句、程序段）之间的联系程度越高，说明内聚性越高，即“高内聚”。

低耦合指的是软件中各个层、模块之间的依赖关系程度越低越好。修改一处，对其他模块的改动越少越好。

高内聚低耦合矛盾吗？

不矛盾，高内聚指的是一个模块红各个元素之间的联系的紧密程度，低耦合指的是各个模块之间的紧密程度。这就好比一个大家庭，包含着很多小家庭，小家庭内的人平时都是在一起生活，联系的紧密程度高（高内聚）；各个小家庭之间的联系的紧密程度就比较低（低耦合）。如果有一个小家庭中某个成员出现状况，对于其他小家庭来说，并没有多大的影响，这就是低耦合；但如果两个小家庭中的成员发生矛盾，这就是耦合。

在后续的案例中，我们将使用三层架构来对案例进行分层。

---

以上就是本篇的所有内容~

若有不足，欢迎指正~