深入探讨：如何理解.Net的三层架构

各层的作用

数据数据访问层:主要是对原始数据（数据库或者文本文件等存放数据的形式）的 *** 作层 而不是指原始数据 也就是说 是对数据的 *** 作 而不是数据库 具体为业务逻辑层或表示层提供数据服务．

业务逻辑层:主要是针对具体的问题的 *** 作 也可以理解成对数据层的 *** 作 对数据业务逻辑处理 如果说数据层是积木 那逻辑层就是对这些积木的搭建

表示层:主要表示WEB方式 也可以表示成WINFORM方式 WEB方式也可以表现成:aspx 如果逻辑层相当强大和完善 无论表现层如何定义和更改 逻辑层都能完善地提供服务

具体的区分方法

数据数据访问层:主要看你的数据层里面有没有包含逻辑处理 实际上他的各个函数主要完成各个对数据文件的 *** 作 而不必管其他 *** 作

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

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

三层结构解释

所谓三层体系结构 是在客户端与数据库之间加入了一个中间层 也叫组件层 这里所说的三层体系 不是指物理上的三层 不是简单地放置三台机器就是三层体系结构 也不仅仅有B/S应用才是三层体系结构 三层是指逻辑上的三层 即使这三个层放置到一台机器上 三层体系的应用程序将业务规则 数据访问 合法性校验等工作放到了中间层进行处理 通常情况下 客户端不直接与数据库进行交互 而是通过/D通讯与中间层建立连接 再经由中间层与数据库进行交换

开发人员可以将应用的商业逻辑放在中间层应用服务器上 把应用的业务逻辑与用户界面分开 在保证客户端功能的前提下 为用户提供一个简洁的界面 这意味着如果需要修改应用程序代码 只需要对中间层应用服务器进行修改 而不用修改成千上万的客户端应用程序 从而使开发人员可以专注于应用系统核心业务逻辑的分析 设计和开发 简化了应用系统的开发 更新和升级工作

那么为什么要应用 中间业务层 呢？举些例子:

我们假设有一段登录代码 则可以这样处理Web程序 外观层负责接收前台页面的数据 然后传给中间层 中间层对数据进行处理 比如格式化 防SQL注入等等一些 这样的数据再传给数据访问层然后与数据库进行 *** 作 比如与数据库的用户名和密码匹配等等一些代码

中间业务层 的用途有很多 例如 验证用户输入数据 缓存从数据库中读取的数据等等……但是 中间业务层 的实际目的是将 数据访问层 的最基础的存储逻辑组合起来 形成一种业务规则 例如 在一个购物网站中有这样的一个规则 在该网站第一次购物的用户 系统为其自动注册 这样的业务逻辑放在中间层最合适

在 数据访问层 中 最好不要出现任何 业务逻辑 ！也就是说 要保证 数据访问层 的中的函数功能的原子性！即最小性和不可再分 数据访问层 只管负责存储或读取数据就可以了

完善的三层结构的要求是:修改表现层而不用修改逻辑层 修改逻辑层而不用修改数据层 否则你的应用是不是多层结构 或者说是层结构的划分和组织上是不是有问题就很难说 不同的应用有不同的理解 这只是一个概念的问题． 理解ASP NET中的三层结构——为什么要分三层？

我们用三层结构主要是使项目结构更清楚 分工更明确 有利于后期的维护和升级 它未必会提升性能 因为当子程序模块未执行结束时 主程序模块只能处于等待状态 这说明将应用程序划分层次 会带来其执行速度上的一些损失 但从团队开发效率角度上来讲却可以感受到大不相同的效果

需要说明一下 三层结构不是 NET的专利 也不是专门用在数据库上的技术 它是一种更加普适的架构设计理念

个人感觉

个人感觉此种架构要在数据库设计上注意表之间的关系 尽力满足主与子的关系 在功能上对用户要有一定的限制 不要表现在对于子表的删除 *** 作一定要慎重 以免造成主表与子表的数据在逻辑上出现的主表的外键在子表中没有相对应的值

对于表的综合查询方法是

先对主表查询 调用主表所对应的DL 再根据主表的记录分别对每一个子表进行查询 将自表的查询结果添加的主表后 形成一个大的查询集合

对于表的 *** 作（增删改）

此时只对主表进行 *** 作 调用主表对应的DL中的 *** 作方法 RL层是逻辑判断层 主要是对页面上传入的数据进行逻辑判断 RL层之上就是UI

如何建立一个三层体系结构解决方案

新建一个空白解决方案 然后

添加 － 新建项目 － 其他项目 － 企业级模版项目 － C#生成块 － 数据访问 （数据层 下简称D层） 添加 － 新建项目 － 其他项目 － 企业级模版项目 － C#生成块 － 业务规则 （业务层 下简称C层） 添加 － 新建项目 － 其他项目 － 企业级模版项目 － C#生成块 － Web用户界面 （界面层 下简称U层） 右键点 解决方案 － 项目依赖项 设置U依赖于D C C依赖于D

对U添加引用D C 对C添加引用D

lishixinzhi/Article/program/net/201311/15434

所谓

三层架构

，是在客户端与数据库之间加入了一个

中间层

，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。

在项目开发的过程中，有时把整个项目分为三层架构，其中包括：

表示层

(UI)、

业务逻辑层

(BLL)和数据访问层(DAL)。三层的作用分别如下：

表示层：为用户提供交互 *** 作界面，这一点不论是对于Web还是WinForm都是如此，就是用户界面 *** 作。我们网站展示给用户看的界面。

业务逻辑层：负责关键业务的处理和数据的传递。复杂的

逻辑判断

和涉及到数据库的

数据验证

都需要在此做出处理。根据传入的值返回用户想得到的值，或者处理相关的逻辑。

数据访问层：见名知意，负责

数据库数据

的访问。主要为业务逻辑层提供数据，根据传入的值来 *** 作数据库，增、删、改或者其它。

以下我简单介绍下一个

用户管理

模块:

为了整个项目的开发方便，我们在项目中会建几个类库

SQLHelper

,BLL,DAL,Model和一个Web网站。为了命名清晰，我们可以这样命名这个三个工程（即在解决方案里添加的类库）:

业务逻辑层(BusinessLogicLayer)：BLL，

命名空间

默认设置为BLL

数据访问层(DataAccessLayer):DAL,命名空间默认设置为DAL

SQL帮助类：SQLHelper,命名空间默认设置为SQLHelper

另外我们为了数据传递的方便，通常再添加一个类库，这个类库是贯穿于整个三层架构中的。即

实体类

。通常命名为Model,命名空间默认值设置为：Models。其中封装的每个类都对应一个实体，通常就是数据库中的一个表。如数据库中的用户表（custom）封装为（custom），将表中的每个字段都封装成共有的属性。

这样三层架构的搭建就基本完成了。这三层有着非常强的依赖关系：

表示层

←

业务逻辑层

←

数据访问层

他们之间的数据传递是双向的，并且通常借助实体类传递数据。

1、易于项目的修改和维护。在项目的开发过程中或者开发后的升级过程中，甚至在项目的移植过程中。这种三层架构是非常方便的。比如项目从Web移植到Form，我们只需要将表示层重新做一遍就可以了。其余两层不用改动，只需添加到现有项目就可以了。如果不采用这种架构，只是将代码写到表示层。那么所有的编码几乎都要重新来了。

2、易于扩展。在功能的扩展上同样如此，如有功能的添加只需把原有的类库添加方法就可了

3、易于代码的重用。这一点就不用解释了。

4、易于分工协作开

还可以加个接口类库Iinterface,

加入

设计模式

，使你的代码灵活性更好源码天空

其实，当我们做一个项目时，我们应该先考虑一下这个项目是不是应该应用三层/多层设计时,

先得考虑下是不是真的需要?

实际上大部分程序就开个WebApplication就足够了,

完全没必要作的这么复杂.

而多层结构,

是用于解决真正复杂的

项目需求

的。

最常用的架构是三层架构。

1. UI Tier（User Interface, 用户接口层）

表示层完成向用户展示界面，提供进一步 *** 作的“驱动接口”，例如按钮，并显示结果。

2. Business Tier（商业层）

完成数据加工，提供加工后的数据给表示层，或者数据层。又可以分为 BLL(Business Logic Layer, 商业逻辑)和DAL(Data Access Layer, 数据访问)。DAL负责存取数据，BLL负责对DAL层 *** 作，对数据进行运算和 *** 作。BLL也负责响应表示层的事件。

3. Data Tier（数据层）

完成数据存储功能。可能是数据库、数据源、XML、文本文件等。

这样就把 数据、业务、显示 分开了。UI层只负责显示给用户看，至于数据怎么处理运算，由BLL进行并响应，处理完的数据，怎么存取由DAL层进行，数据怎么存在介质上由Data层完成，DAL就不用管。各层之间相对比较独立，物理依赖性就不那么高了，有时候就只需要编译改动过的层。

一般对开发和设计人员来说，只需要对UI, BLL, DAL 进行设计开发，DATA Tier由OS或者DBMS来进行，你只需要按“格式”来存取数据即可。

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

1. UILayer里面只有少量(或者没有)的SQL语句或者存储过程调用, 并且这些语句保证不会修改数据?

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

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

4. 三个模块, 可以分别运行于不同的服务器吗?

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

1. 最关键的, UI层只能作为一个外壳, 不能包含任何BizLogic的处理过程

2. 设计时应该从BLL出发, 而不是UI出发. BLL层在API上应该实现所有BizLogic, 以面向对象的方式

3. 不管数据层是一个简单的SqlHelper也好, 还是带有Mapping过的Classes也好, 应该在一定的抽象程度上做到系统无关

4. 不管使用COM+(Enterprise Service), 还是Remoting, 还是WebService之类的远程对象技术, 不管部署的时候是不是真的分别部署到不同的服务器上, 最起码在设计的时候要做这样的考虑, 更远的, 还得考虑多台服务器通过负载均衡作集群

所以考虑一个项目是不是应该应用三层/多层设计时, 先得考虑下是不是真的需要? 实际上大部分程序就开个WebApplication就足够了, 完全没必要作的这么复杂. 而多层结构, 是用于解决真正复杂的项目需求的.”

而且三层之间有时候也不用那么严格，得根据实际业务逻辑来判断使用。这也是软件开发所以没有一个固定流程的原因。

---