目录
通常意义上的三层架构是指：
表示层 / 表现层 / (用户)界面层（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、增加了代码量，增加了工作量，增加了访问成本。