低层数据库嘛 当然是存放数据的
中间的逻辑层就是来计算和控制以及联系 上下2层的
表示成就不用说了 就是给客户看的 直接用来操作的
这3层应该什么关于.NET的基础书籍上都有说明的把
在过去应用系统开发过程中，CLIENT/SERVER体系结构得到了广泛的应用 。其特点是，应用程序逻辑通常分布在客户和服务器两端，客户端发出数据资源访问请求，服务器端将结果返回客户端。但CLIENT/SERVER结构存在着很多体系结构上的问题，比如：当客户端数目激增时，服务器端的性能会因为负载过重而大大衰减；一旦应用的需求发生变化，客户端和服务器端的应用程序都需要进行修改，给应用维护和升级带来了极大的不便；大量的数据传输增加了网络的负载等等。
所谓三层体系结构，是在客户端与数据库之间加入了一个"中间层"，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互
所谓三层架构
，是在客户端与数据库之间加入了一个
中间层
，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有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就足够了,
完全没必要作的这么复杂.
而多层结构,
是用于解决真正复杂的
项目需求
的。
