从 MVC 架构到三层（3-Tier）架构

一、MVC 存在的痛点问题

对于业务逻辑不甚复杂的场景，MVC 尚能胜任。但随着前端 MVVM（Model-View-View-Model）开发模式的兴起，尤其是前端框架如 Vue、React 的普及，服务端的 MVC 设计模式使用场景变得越来越少，因为已不再需要服务端渲染 View 。

此外，MVC 其实分层设计模式仍然粒度较粗：

Model 层级的代码既维护数据，也封装着业务逻辑，随着业务逻辑变得越来越复杂，这一层功能逻辑会变得越来越臃肿不易维护。
对于团队管理来讲，Controller 和 Model 的职责边界比较模糊，对于开发人员写好代码的要求会比较高。

二、3-Tier Architecture（三层架构）

虽然有时 MVC 也被称为三层架构，但三层架构是有特定术语（3-Tier Architecture）的。

2.1 表示层 — UI

User Interface 位于三层构架的最上层，与用户直接接触，主要是 B/S 中的 WEB 页面，也可以是 API 接口。表示层的主要功能是实现系统数据的传入与输出，在此过程中不需要借助逻辑判断操作就可以将数据传送到 BLL 系统中进行数据处理，处理后会将处理结果反馈到表示层中。换句话说，表示层就是实现用户界面 / API 接口功能，将用户的需求传达和反馈，并用 BLL 或者是 Model 进行调试，保证用户体验。

2.2 业务逻辑层 — BLL

Business Logic Layer 的功能是对具体问题进行逻辑判断与执行操作，接收到表现层 UI 的用户指令后，会连接数据访问层 DAL，业务逻辑层在三层构架中位于表示层与数据层中间位置，同时也是表示层与数据层的桥梁，实现三层之间的数据连接和指令传达，可以对接收数据进行逻辑处理，实现数据的增删改查等功能，并将处理结果反馈到表示层 UI 中，实现软件功能。

2.3 数据访问层 — DAL

Data Access Layer 是数据库的主要操控系统，实现数据的增删改查等操作，并将操作结果反馈到业务逻辑层 BLL。在实际运行的过程中，数据访问层没有逻辑判断能力，为了实现代码编写的严谨性，提高代码阅读程度，一般软件开发人员会在该层中实现通用数据能力进行封装（例如通过 ORM 组件）来保证数据访问层 DAL 数据处理功能。

2.4 模型定义层 — Model

模型定义也常用 Entity 实体对象来表示，主要用于数据库表的映射对象，在信息系统软件实际开发的过程中，要建立对象实例，将关系数据库表采用对象实体化的方式表现出来，辅助软件开发中对各个系统功能的控制与操作执行。建立实体类库，进而实现各个结构层的参数传输，提高代码的阅读性。从本质上看，实体类库主要服务于表示层、业务逻辑层以及数据访问层，在三层之间进行数据参数传输，强化数据表示的简约性。

需要注意区分的是，这里的Model和MVC设计模式中的Model虽然都是一个名字但是差别巨大，职责完全不同。