三层架构理论篇

三层架构的学习，是我们从思想上发生转变的一个过渡阶段。老规矩，开始学习三层架构之前，我们首先要弄明白一些基础的理论知识，例如什么是三层架构，为什么会有三层架构，为什么要学习或者为什么要用三层架构？带着这几个疑问去阅读下面的总结，看看你能从中找到想要的答案吗？

1.三层的由来

最早的程序是不分层的，后来随着客户机/服务器系统的出现，分层的概念就明显了。这样的系统是两层结构，客户端包含界面也包含应用代码。服务器端就是数据库。但是程序逻辑复杂并易变时，这样就会有很多缺点，冗余代码，不利于复用，不利于分工等等。随着面向对象编程思想的普及，三层架构的系统也逐渐进入人们的视野并被广泛接受。这种方式可以把复杂的程序逻辑从界面中抽离出来，用对象加以建模和组织。

 

2.三层架构

通常意义上的三层架构就是将整个业务应用划分为：显示层UI,业务逻辑层BLL,数据访问层DAL。用一张图来展示

 

2.1显示层（UI=User Interface）

概念

通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。

作用

向用户展现特定业务数据

采集用户的输入信息和操作

原则

只负责显示和采集用户操作,不包含任何的业务相关的逻辑处理

 

总结：就是知道要干什么+提供的相应的数据信息

 

2.2业务逻辑层（BLL=Business Logic Layer）

概念

针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。

作用

从DAL中获取数据，以供UI显示用

从UI 中获取用户指令和数据，执行业务逻辑

从UI中获取用户指令和数据，通过DAL写入数据源

原则

负责处理业务逻辑.通过获取UI传来的操作指令,决定执行业务逻辑,在需要访问数据源的时候直接交给DAL处理.处理完成后,返回必要数据给UI.

总结：对业务逻辑进行处理。

 

2.3 数据访问层（DAL=Data Access Layer）

概念

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

作用

从数据源加载数据（select）

向数据源写入数据（insert、update）

从数据源删除数据（delete）

原则

只提供基本的数据访问,不包含任何业务相关的逻辑处理

总结：跟数据打交道，对数据源读数据、写数据、删数据。

 

2.4 三者之间的关系

单层向上引用：UI——>BLL——>DAL，UI引用BLL,BLL引用DAL,UI可能间接引用DAL

执行机制：

UI提出请求并搜集一定的用户数据传递给业务逻辑层

业务逻辑层将请求转给DAL

DAL处理加工返回给BLL

BLL将结果返回给UI

见图示：



为了防止相互引用和交叉引用，此时需要引进业务实体Entity.

2.5 业务实体Entity

业务实体用于封装实体类数据结构，一般用于映射数据库的数据表或视图，用以描述业务汇总客观存在的对象。

业务实体独立于三个层次集,不引用其中任何一个。而其他三个层次级都会引用业务实体

作用

业务实体分离出来是为了更好的解耦，为了更好地发挥分层的作用，更好地进行复用和扩展，增加灵活性。

 

总结:业务实体就是封装数据并在三层间传输数据.

3 三层架构的优缺点

3.1 优点

1.开发人员可以只关注整个结构中的其中某一层

2.可以很容易的用新的实现来替换原有层次的实现

3.可以降低层与层之间的依赖

4.有利于标准化

5.利于各层逻辑的复用

 

3.2 缺点

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

2.有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

3. 增加了开发成本

更多详细信息请参见：http://baike.baidu.com/view/687468.htm

 

4 适用范围

当然，不是所有的程序都适合使用三层架构，如果业务逻辑简单或者没有真正的数据存储层时，是不需要使用三层的。三层架构只适用于既有数据访问层又有业务逻辑层的程序中。

5 总结

 

通过将显示层、业务逻辑层和数据访问层分别封装，每层做些什么其他层是完全看不到的，因此更改、更新某层，都不需要再重新编译或者更改全部的层了。例如，如果把数据访问代码与业务逻辑层分离，当数据库服务器更改后，我们只需要更改数据访问的代码。这样，既做到了“强内聚、低耦合”，又遵守了开放-封闭原则。

链接：http://blog.csdn.net/u010773667/article/details/22478449