[转]三层架构

目录

• 什么是三层架构？
• 与两层的区别？
• 什么情况下需要使用？
• 优缺点

原文链接：三层架构——CSDN
原文链接：三层架构(我的理解及详细分析)——CSDN

什么是三层架构？

三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。

DAL(数据访问层): 与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。
（当然这些操作都是基于UI层的。用户的需求反映给界面（UI），UI反映给BLL，BLL反映给DAL，DAL进行数据的操作，操作后再一一返回，直到将用户所需数据反馈给用户）

1. DAL的作用
   从数据源加载数据（select）
   向数据源写入数据（Insert/Update)
   从数据源删除数据（Delete)

2. DAL 中常用的技术（为了和数据源打交道）
   ADO.NET+SQL语句
   O/R Mapping框架 Nhiberate(可跨数据库)
   访问SQL Server数据库时 Linq to SQL

UI(表现层): 主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。

1. UI的作用
   向用户展现特定业务数据。
   采集用户的输入信息和操作指令。

2. UI设计的原则
   用户至上，兼顾简洁。（用户需要什么就做什么；在满足用户的要求下，越简单越好。）

3. UI众常用的技术
   WindowsForm：Form、Control
   ASP .NET：aspx、ascx、master、html

BLL:(业务逻辑层): UI层和DAL层之间的桥梁。实现业务逻辑。业务逻辑具体包含：验证、计算、业务规则等等。

1. BLL的作用
   从DAL中获取数据，以供UI显示用。
   从UI中获取用户指令和数据，执行业务逻辑。
   从UI中获取用户指令和数据，通过DAL写入数据源。

2. BLL的职责机制
   UI->BLL->UI
   UI->BLL->DAL->BLL->UI

Entity(实体层)：它不属于三层中的任何一层，但是它是必不可少的一层。

1. Entity在三层架构中的作用
   实现面向对象思想中的"封装"。
   贯穿于三层，在三层之间传递数据。（确切的说实体层贯穿于三层之间，来连接三层）
   每一层（UI—>BLL—>DAL）之间的数据传递（单向）是靠变量或实体作为参数来传递的，这样就构造了三层之间的联系，完成了功能的实现。

2. 三层及实体层之间的依赖关系
   

3. 对于初学者来说，可以这样理解：每张数据表对应一个实体，即每个数据表中的字段对应实体中的属性。（当然，事实上不是这样，为什么？）
   可能我们需要的实体在数据表对应的实体中并不存在
   我们完全可以将所有数据表中的所有字段都放在一个实体里

与两层的区别？

两层：

（当任何一个地方发生变化时，都需要重新开发整个系统。"多层"放在一层，分工不明确耦合度高——难以适应需求变化，可维护性低、可扩展性低）

三层：

（发生在哪一层的变化，只需更改该层，不需要更改整个系统。层次清晰，分工明确，每层之间耦合度低——提高了效率，适应需求变化，可维护性高，可扩展性高）

什么情况下需要使用？

不需要的情况：1业务逻辑简单，2没有真正的数据存储层。
需要的情况：当业务复杂到一定程度，当数据存储到相应的数据库或独立数据存储介质。把数据访问独立数据库单独存在，把业务独立UI单独存在。

优缺点

优点

1. 开发人员可以只关注整个结构中的其中某一层；
2. 可以很容易的用新的实现来替换原有层次的实现；
3. 可以降低层与层之间的依赖；
4. 有利于标准化；
5. 利于各层逻辑的复用。
6. 结构更加的明确
7. 在后期维护的时候，极大地降低了维护成本和维护时间

缺点

1. 降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2. 有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3. 增加了开发成本。