---

通常意义上的三层架构是指：

表示层 / 表现层 / (用户)界面层（UI：User Interface layer）

业务逻辑层 / 应用程序层 / 领域层（BLL：Business Logic Layer）

数据访问层 / 数据层 / 持久层（DAL：Data access layer）

表示层 / 表现层 / (用户)界面层 UI

主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。

为客户端提供应用程序的访问。

UI层不只是一个个用户界面，也需要代码。

没有涉及到业务逻辑，直接传参、函数、方法调用，没有涉及到与数据库打交道的SQL语句和ADO.net。

业务逻辑层 / 应用程序层 / 领域层BLL

承上启下，UI层和DAL层之间的桥梁，对于一个支持可扩展的架构尤为关键。

对数据访问层而言是调用者，对表示层来说是被调用者。

负责数据处理、传递。

实现业务逻辑。

业务逻辑具体包含：验证、计算、业务规则等等。

没有涉及到界面控件，没有涉及到业务逻辑；只有与数据库打交道的SQL语句和ADO.net

数据访问层 / 数据层 / 持久层DAL

该层所做事务直接操作数据库，针对数据的增添、删除、修改、查找等。

将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。

三层框架之间的关系

用户的需求反映给UI，UI反映给BLL，BLL反映给DAL，DAL进行数据的操作，操作后再一一返回，直到将用户所需数据反馈给用户。

实体层 / 数据库实体类Entity

对数据对象进行封装，也有一些简单的功能。

不属于三层架构，但必不可少。

作为一个类库，起到封装数据库的作用。

贯穿三层之间，在三层之间传递数据。

三层架构的优势

1，结构清晰、耦合度低，符合“高内聚低耦合”的思想

2，可维护性高，可扩展性高

3，利于开发任务同步进行, 容易适应需求变化

三层架构的劣势

1、降低了系统的性能。

如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

2、有时会导致级联的修改。

这种修改尤其体现在自上而下的方向。

如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

3、增加了代码量，增加了工作量，增加了访问成本。

注：符合 MVC（模型-视图-控制器） 设计模式的代码不一定是三层架构，但如果是三层架构的代码，一定是符合 MVC 设计模式的

---

参考：
三层架构详解 | 菜鸟教程 - runoob.com