从 MVC 架构到三层(3-Tier)架构

一、MVC 存在的痛点问题

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

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

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

二、3-Tier Architecture(三层架构)

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

从 MVC 架构到三层(3-Tier)架构_第1张图片

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虽然都是一个名字但是差别巨大,职责完全不同。

你可能感兴趣的:(Go,mvc,架构,前端)