浅谈三层架构

.NET三层架构

什么是三层架构？

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

在分层架构中还有实体层（Model）、单元测试层、工厂、接口等等。在这里我们只讲简单三层架构，其中涉及到实体层。

各层的主要作用：

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

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

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

实体层（Model）：Model在各层之间起到了一个数据传输的桥梁作用。

注：三层架构与MVC是有区别的，MVC是一种设计模式。

     三层中各层之间的联系：

     Model     Model    Model

UI——>BLL——>DAL——>数据库

UI层调用BLL中的方法，BLL调用DAL中的方法，DAL对数据库进行增删改查。各层之间通过Model进行数据传输。（方法的参数为Model层中的某个类，方法返回类型为Model层中的某个类）

为什么要使用三层架构？

1、高内聚低耦合，降低各层之间的依赖。(修改表现层而不用修改逻辑层,修改逻辑层而不用修改数据层)

2、开发人员可以只关注整个结构中的其中某一层，分工明确。

3、利于各层的复用。

4、在三层架构中可以更换某个层而不影响其他层，比如：本来是一个C/S项目，现在想换成B/S项目，只需把节目层换掉而不必改变其他层。同理，现在项目用的是SQL Server数据库想换成Oracle数据库，只需换掉DAL层就可以。

 

三层架构的缺点：

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

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

 

三层架构实例：

稍后放出。