深入浅出三层架构三层架构概念：代码剖析：总结：

<a></a>

<b>阅读目录</b>

<a href="http://www.cnblogs.com/OceanEyes/archive/2012/02/10/SANCENG.html#_label0">三层架构概念：</a>

<a href="http://www.cnblogs.com/OceanEyes/archive/2012/02/10/SANCENG.html#_label1">代码剖析：</a>

<a href="http://www.cnblogs.com/OceanEyes/archive/2012/02/10/SANCENG.html#_label2">总结：</a>

这几天看了不少三层架构的资料，整理整理

——故写篇博文谈谈自己的看法。

三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想，复杂项目不能把SQL语句直接写到程序里，不模块话，难以维护。应该采取三层架构。

1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。

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

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

简单的说，UI层调用BLL，BLL调用DAL，数据用Model进行传递，Model为各层之间架起了数据传输的桥梁。

参考模型：UI&lt;--&gt;Model&lt;--&gt;BLL&lt;--&gt;Model&lt;--&gt;DAL

下面我以一个简单的例子来细数三层架构：

新建一个项目（Windows 窗体应用程序），再在根目录下新建3个文件夹，分别是Model,DAL,BLL。

在Model下添加一个Person类

在DAL下添加一个SQLHelper类和一个PersonDAL类。

在BLL下添加PersonBLL类

SQLHelper类，封装了数据库操作的方法：

进行逻辑判断的BLL层代码看似是这样的：

PersonBLL.cs代码如下：

UI层进行测试：

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

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

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

　　4、有利于标准化；

　　5、利于各层逻辑的复用。

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

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

　　3、增加了开发成本。

本文转自木宛城主博客园博客，原文链接：http://www.cnblogs.com/OceanEyes/archive/2012/02/10/SANCENG.html，如需转载请自行联系原作者