三层架构解析

三层架构

　　三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：界面

层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data 

access layer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计

中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三

层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。

中文名：三层架构 

外文名：3-tier architecture 

分    类：界面层、业务逻辑层、数据访问层 

目    的：“高内聚，低耦合”的思想 

优    点：降低层与层之间的依赖 标准化 

缺    点：系统架构复杂，不适合小型项目 

 

 三层结构原理编辑

　　3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。

所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里

所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，

也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即把这三个层放置

到一台机器上。

三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。

通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层

建立连接，再经由中间层与数据库进行交互。

 

各层的作用

1：数据访问层：主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作

层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑

层或表示层提供数据服务．

2：业务逻辑层：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数

据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。

3：界面层：主要表示WEB方式，也可以表示成WINFORM方式，WEB方式也可以

表现成：aspx，如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都

能完善地提供服务。

 

区分方法

1：数据访问层：主要看数据层里面有没有包含逻辑处理，实际上它的各个函数主要完

成各个对数据文件的操作。而不必管其他操作。

2：业务逻辑层：主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。

3：表示层：主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。

 

　　表示层 

　　位于最外层（最上层），最接近用户。用于显示数据和接收用户输入的数据，为用户提

供一种交互式操作的界面。

 

业务逻辑层 

　　业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。它的关

注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即

是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为

领域层。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一书

中，将整个架构分为三个主要的层：表示层、领域层和数据源层。作为领域驱动设计的

先驱Eric Evans，对业务逻辑层作了更细致地划分，细分为应用层与领域层，通过分层

进一步将领域逻辑与领域逻辑的解决方案分离。

　　业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据

交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层

对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果

在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖

关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、

可替换的“抽屉”式架构。正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤

为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示

层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖

关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。

 

数据层 

　　数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问，可以访问数据

库系统、二进制文件、文本文档或是XML文档。

简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入

ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。

 

规则

　　三层结构的程序不是说把项目分成DAL,BLL,WebUI三个模块就叫三层了，下面几个问

题在你的项目里面：

⒈ UILayer里面只有少量（或者没有）SQL语句或者存储过程调用，并且这些语句保

证不会修改数据?

⒉ 如果把UILayer拿掉，你的项目还能在Interface/API的层次上提供所有功能吗?

⒊ 你的DAL可以移植到其他类似环境的项目吗?

⒋ 三个模块，可以分别运行于不同的服务器吗?

如果不是所有答案都为YES，那么你的项目还不能算是严格意义上的三层程序. 三层程序有一些需要约定遵守的规则：

⒈ 最关键的，UI层只能作为一个外壳，不能包含任何业务逻辑(BizLogic)的处理过程

⒉ 设计时应该从BLL出发，而不是UI出发. BLL层在API上应该实现所有BizLogic，

以面向对象的方式

⒊ 不管数据层是一个简单的SqlHelper也好，还是带有Mapping过的Classes也好，

应该在一定的抽象程度上做到系统无关

⒋ 不管使用COM+(Enterprise Service），还是Remoting，还是WebService之类的

远程对象技术，不管部署的时候是不是真的分别部署到不同的服务器上，最起码在设计

的时候要做这样的考虑，更远的，还得考虑多台服务器通过负载均衡作集群

所以考虑一个项目是不是应该应用三层/多层设计时，先得考虑下是不是真的需要? 实

际上大部分程序就开个WebApplication就足够了，完全没必要作的这么复杂. 而多层

结构，是用于解决真正复杂的项目需求的。

 

优缺点

0.1优点 

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

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

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

4、有利于标准化；

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

6、结构更加的明确

7、在后期维护的时候，极大地降低了维护成本和维护时间

0.2缺点 

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

2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需

要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据

访问层中都增加相应的代码。

3、增加了开发成本。

 

与MVC的区别编辑

　　MVC（模型Model-视图View-控制器Controller）是一种架构模式，可以用它来创建在

域对象和UI表示层对象之间的区分。

 

　　同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其

他的两个层。

 

　　在三层架构中没有定义Controller的概念。这是最不同的地方。而MVC也没有把业务

的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。

在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是

不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑

与访问数据组成的。

转载自：https://www.cnblogs.com/zhanglizhi/p/4922170.html