初识“三层“

什么是三层？分别指的哪三层？

通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。

表现层，位于最上层，通俗地讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。

业务逻辑层，处于数据访问层和表现层中间，是对数据层的操作，对数据业务逻辑处理。系统主要功能和业务逻辑都在业务逻辑层进行处理，是系统架构的核心之所在，包括业务规则的制定、数据访问、业务流程的实现、合法性校验等工作。起到了数据交换中承上启下的作用。

数据访问层其功能主要是负责数据库的访问，简单说的就是实现对数据库中的数据进行增删改查。

值得注意的是，三层指的是逻辑上的三层，即使这三个层放置到一台机器上。

三者之间的依赖关系：

数据访问层的类，直接访问数据库，实现基本记录操作。

业务逻辑层的类，调用相关的数据访问类，实现用户所需功能。

表现层：部署控件后，调用业务逻辑层的类，实现功能。

那么为什么要分层呢？分层有什么好处呢？

分层的目的即为了“高内聚，低耦合”的思想。 概况来说，分层式设计可以达到：分散关注、松散耦合、逻辑复用、标准定义的作用。

一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。每个开发人员的任务得到了确认，开发进度就可以迅速得到提高。

如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响是极为严重的。降低层与层之间的依赖性，既可以保证扩展，又可以复用。每个功能模块一旦定义好统一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。

然而任何事物都有它的两面性，分层也不例外：分层也会有它的弊端：

首先分层降低了系统的性能。因为如果不采用分层式结构，很多业务可以直接访问数据库获得数据，但分层后却必须通过中间层来完成。

其次分层有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如在表现层增加一个功能，那么就得在相应的业务逻辑层和数据访问层中都增加相应的代码。

因此，不是所有的项目都需要分层的。一个项目是否要应用分层设计时，先得考虑它是否真的需要？分层结构，是用于解决真正复杂的项目需求的。