三层架构#
三层架构是什么?#
三层架构(Three-Tier Architecture)是一种常见的软件架构模式,它将应用程序划分为三个逻辑层,分别是表示层(Presentation Layer)、业务逻辑层(Business Logic Layer)和数据访问层(持久层)(Data Access Layer)。这种架构的目的是实现应用程序的高内聚、低耦合,从而提高系统的可维护性、可扩展性和复用性。
三层架构的三个层次#
- 表示层(Presentation Layer)
- 负责与用户交互,展示数据并接收用户输入。
- 通常包括用户界面(UI)和用户交互逻辑。
- 业务逻辑层(Business Logic Layer)
- 负责处理核心业务逻辑,执行具体的业务规则。
- 将表示层的输入转化为对数据的操作,并将处理结果返回给表示层。
- 该层的主要职责是保证数据的完整性和一致性。
- 数据访问层(Data Access Layer)
- 负责与数据库进行交互,执行 CRUD 操作(创建、读取、更新和删除)。
- 提供对数据存储和访问的抽象接口,屏蔽数据库的具体实现细节。

每一层都各负其责,那么该如何将三层联系起来呢?在后端面向对象的系统重,就需要我们的实体层。
**Entity(实体层):**它不属于三层中的任何一层,但是它是必不可少的一层,每一层(UI—>BLL—>DAL)之间的数据传递(单向)是靠变量或实体作为参数来传递的,这样就构造了三层之间的联系,完成了功能的实现
对于初学者来说,可以这样理解:后端实际最终是和数据打交道,其实也就是和数据库打交道,每张数据表对应一个实体,即每个数据表中的字段对应实体中的属性
注意:当然,事实上不是这样。这里这么说只是为了简单理解?
1、可能我们需要的实体在数据表对应的实体中并不存在,比如界面的密码验证再次输入信息
2、数据库中的字段也不是必须要对应实体,比如删除的字段(有一些表数据我们并不会真正的删除,而是通过更新数据,比如0或者1,达到查询的时候的过滤效果而已)
三层架构的优点#
- 分离关注点:每个层次关注不同的职责,代码逻辑更加清晰。
- 可维护性高:修改某一层的代码不会影响其他层。
- 可复用性高:业务逻辑和数据访问层可以在不同的表示层中复用。
举例来说,比如:
**服务员:**只管接待客人;
**厨师:**只管做客人点的菜;
**采购员:**只管按客人点菜的要求采购食材;
他们各负其职,服务员不用了解厨师如何做菜,不用了解采购员如何采购食材;厨师不用知道服务员接待了哪位客人,不用知道采购员如何采购食材;同样,采购员不用知道服务员接待了哪位客人,不用知道厨师如何做菜。
这样就能做到解耦:
服务员(UI层)请假——另找服务员;
厨师(BLL层)辞职——招聘另一个厨师;
采购员(DAL)辞职——招聘另一个采购员;
顾客反映:
- 1、你们店服务态度不好——服务员的问题。开除服务员;
- 2、你们店口味太差——厨师的问题。换厨师;
任何一层发生变化都不会影响到另外一层!!!
MVC#
MVC是什么?#
MVC(Model-View-Controller)是一种广泛应用的软件架构模式,用于组织应用程序的代码结构。它将应用程序分为三个主要部分:模型(Model)、视图(View)**和**控制器(Controller)。这种模式的目标是将应用程序的逻辑与用户界面分离,从而提高代码的可维护性和可扩展性。
MVC的三个组件#
- 模型(Model)
- 代表应用程序的数据或业务逻辑。
- 负责数据的获取、存储、验证以及数据库操作。
- 模型不关心视图和控制器如何交互,只专注于数据和业务逻辑。
- 视图(View)
- 负责展示数据,也就是用户界面(UI)。
- 视图从模型中获取数据,并将其展示给用户。视图并不直接处理业务逻辑。
- 它的主要职责是“显示”,在传统的服务器渲染中,可能使用的是freemarker,jsp,thymeleaf等模版引擎。在前后端分离的体系中,通常指的是客户端框架(Vue、React、angular等)负责的部分
- 控制器(Controller)
- 负责处理用户的输入,调度Service服务,以及进行API的路由管理
- 控制器接收用户请求,调用相应的模型逻辑,处理数据,然后将数据传递给视图进行展示。
- 控制器起到协调模型和视图的作用,确保它们正确交互。
当一个HTTP请求到达服务器时,它首先会被Controller层接收,Controller层会根据请求调用Model层中的相应模块来处理业务逻辑,并将处理的结果返回给View层进行展示。大致流程如图:

MVC的优点#
- 分离关注点:将数据处理、用户界面和控制逻辑分开,减少了代码的耦合性。
- 提高可维护性:由于每个组件都独立,可以更容易地进行修改和扩展。
- 易于扩展和复用:视图和模型可以独立发展,控制器可以用来协调不同的组件。
- 支持多视图:相同的模型可以有多个视图(例如,Web界面和移动端界面),而不需要重复业务逻辑。
三层架构与MVC的区别#
虽然三层架构和MVC在概念上有类似之处,都会将系统划分为不同的部分以实现职责分离,但它们的关注点、应用范围和目的是不同的。你会觉得它们相似,是因为它们都强调分层和职责分离,但它们的层次划分和关注点不一样。
1. 关注点不同#
| 三层架构 | MVC |
|---|---|
| 关注的是应用程序的逻辑分层。 | 关注的是前端展示和交互的分层。 |
| 强调应用程序的后端逻辑组织,将系统划分为:表示层(UI 层)、业务逻辑层、数据访问层。 | 强调用户界面与业务逻辑分离,主要用于处理用户界面和交互逻辑。 |
| 面向整个系统,特别是后端开发。 | 面向前端与后端交互部分,强调视图与控制逻辑的分离。 |
2. 层次划分不同#
三层架构的层次#
- 表示层(UI 层)
- 提供用户界面,展示数据,接收用户输入(通常是前端)。
- 业务逻辑层(BLL,Business Logic Layer)
- 处理业务规则,是系统的核心层,封装具体的业务逻辑。
- 数据访问层(DAL,Data Access Layer)
- 与数据库交互,负责数据的存取与持久化。
MVC的层次#
- 模型(Model)
- 负责处理数据和业务逻辑。
- 视图(View)
- 负责展示数据和用户界面。
- 控制器(Controller)
- 负责接收用户请求,调用模型处理数据,更新视图。
区别点:
- 三层架构的层次划分更偏向后端服务分层,关注应用程序如何处理请求、执行业务逻辑并与数据库交互。
- MVC 的层次划分更偏向于前端与后端交互部分,关注用户界面与业务逻辑的解耦。
3. 应用范围不同#
| 三层架构 | MVC |
|---|---|
| 常用于整个应用系统的架构设计,包括后端和数据库。 | 常用于前端框架或Web应用的界面交互层设计。 |
| 强调将后端的不同职责进行分层,特别适用于多层次的后端服务。 | 强调用户界面和业务逻辑的解耦,适用于前端界面展示与交互。 |
| 更适合大型企业系统,尤其是需要清晰业务逻辑和数据访问层的应用。 | 更适合前端开发和Web开发中用户界面的分层设计。 |
4. 结合使用#
事实上,三层架构和MVC可以结合使用,它们并不互斥。例如:
- 表示层(UI 层)**中可以采用**MVC模式,将前端代码组织为视图、模型和控制器,处理用户交互逻辑。
- 业务逻辑层和数据访问层则采用传统的三层架构模式,处理核心业务逻辑和数据存储。
