三层结构的三层是指表示层、业务逻辑层、数据访问层。
表示层：位于最外层，离用户最近，用于显示数据和接受用户输入的数据，为用户提供一种交互式操作界面。
表示层一般为Windows应用程序或Web应用程序。
业务逻辑层：是表示层和数据访问层之间通信的桥梁，主要负责数据的传递和处理，例如数据有效性的检验、业务逻辑描述相关功能。
业务逻辑层通常为类库。
数据访问层：主要实现对数据的保存和读取操作。
数据访问，可以访问关系数据库、文本文件或是XML文档。
数据访问层通常为类库。
在三层结构中，各层之间相互依赖：表示层依赖于业务逻辑层，业务逻辑层依赖于数据访问层。
在三层结构中，各层之间的数据传递方向分为请求与响应两个方向：表示层接受用户的请求，根据用户的请求去通知业务逻辑层，业务逻辑层收到请求，首先对请求进行阅读审核，然后将请求通知数据访问层或直接返回给表示层，数据访问层收到请求后便开始访问数据库；数据访问层通过对数据库的访问得到请求结果，并把请求结果通知业务逻辑层，业务逻辑层收到请求结果，首先对请求结果进行阅读审核，然后将请求结果通知表示层，表示层收到请求结果，并把结果展示给用户。
使用实体类构建三层结构实体类，简单地说是描述一个业务实体的类，业务实体直观一点理解就是整个应用系统业务所涉及的对象，从数据存储来讲，业务实体救是存储应用系统信息的数据表，我们将每一个数据表中的字段定义成属性，并将这些属性用一个类封装，这个类就是实体类。
业务实体可以认为属于业务逻辑层，当然，可以将业务实体单独作为一层，称为业务实体层。
表示层、业务逻辑层、数据访问层都依赖于业务实体。
各层之间数据的传递主要是实体对象（业务信息封装在实体对象中）。
博客系统数据库：创建数据库MyBlog、用户表Users、日志信息表Articles、评论信息表Comments创建空白解决方案Blog.sln添加类库BlogModels（模型层），分别添加User.cs、Article.cs、Comment.cs（与数据库中的表一一对应）1:6:using System;7:using System.Collections.Generic;8:using System.Text;9:10:namespace BlogModels11:{12://实体类前面一般加上序列化属性，它会对实体类中的所有字段、属性进行序列化处理。
13://序列化的主要目的是为了提高数据传输中的性能与安全性14: [Serializable()]15:publicclass User16:{17:privateint id;18:privatestring loginId = String.Empty;19:privatestring loginPwd = String.Empty;20:privatestring name = String.Empty;21:22://构造函数23:public User() { }24:25:////////////////////////////////////////////26:// Primary Key27:////////////////////////////////////////////28://[DBField("Id")]29:publicint Id30:{31: get { returnthis.id; }32: set { this.id = value; }33:}34:35:////////////////////////////////////////////36:// Properties37:////////////////////////////////////////////38://[DBField("LoginId")]39:publicstring LoginId40:{41: get { returnthis.loginId; }42: set { this.loginId = value; }43:}44:45://[DBField("LoginPwd")]46:publicstring LoginPwd47:{48: get { returnthis.loginPwd; }49: set { this.loginPwd = value; }50:}51:52://[DBField("Name")]53:publicstring Name54:{55: get { ; }56: set { = value; }57:}58:}59:}其他两个类与之相似~添加类库BlogDAL（数据访问层）添加类库BlogBLL（业务逻辑层）添加网站Blog（表示层）希望朋友们留下自己对三层架构的理解。
三层体系结构的概念1.用户界面表示层(USL)2.业务逻辑层(BLL)3.数据访问层(DAL)BLL将USL与DAL隔开了，并且加入了业务规则∙各层的作用∙1：数据数据访问层:主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库,具体为业务逻辑层或表示层提供数据服务．2：业务逻辑层:主要是针对具体的问题的操作，也可以理解成对数据层的操作,对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。
3：表示层:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成:aspx,如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地提供服务。
∙具体的区分方法1：数据数据访问层:主要看你的数据层里面有没有包含逻辑处理，实际上他的各个函数主要完成各个对数据文件的操作。
而不必管其他操作。
2：业务逻辑层:主要负责对数据层的操作。
也就是说把一些数据层的操作进行组合。
3：表示层:主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。
∙三层结构解释所谓三层体系结构，是在客户端与数据库之间加入了一个中间层，也叫组件层。
这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。
通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交换.开发人员可以将应用的商业逻辑放在中间层应用服务器上，把应用的业务逻辑与用户界面分开。
在保证客户端功能的前提下，为用户提供一个简洁的界面。
这意味着如果需要修改应用程序代码，只需要对中间层应用服务器进行修改，而不用修改成千上万的客户端应用程序。
从而使开发人员可以专注于应用系统核心业务逻辑的分析、设计和开发，简化了应用系统的开发、更新和升级工作。
∙那么为什么要应用“中间业务层”呢？举些例子:我们假设有一段登录代码，则可以这样处理Web程序，外观层负责接收前台页面的数据，然后传给中间层，中间层对数据进行处理，比如格式化，防SQL注入等等一些，这样的数据再传给数据访问层然后与数据库进行操作，比如与数据库的用户名和密码匹配等等一些代码。
∙“中间业务层”的用途有很多，例如：验证用户输入数据、缓存从数据库中读取的数据等等……但是，“中间业务层”的实际目的是将“数据访问层”的最基础的存储逻辑组合起来，形成一种业务规则。
例如：“在一个购物网站中有这样的一个规则：在该网站第一次购物的用户，系统为其自动注册”。
这样的业务逻辑放在中间层最合适：在“数据访问层”中，最好不要出现任何“业务逻辑”！也就是说，要保证“数据访问层”的中的函数功能的原子性！即最小性和不可再分。
“数据访问层”只管负责存储或读取数据就可以了。
∙中的三层结构说明完善的三层结构的要求是:修改表现层而不用修改逻辑层,修改逻辑层而不用修改数据层。
否则你的应用是不是多层结构,或者说是层结构的划分和组织上是不是有问题就很难说.不同的应用有不同的理解，这只是一个概念的问题．∙∙理解中的三层结构——为什么要分三层？我们用三层结构主要是使项目结构更清楚，分工更明确，有利于后期的维护和升级。
它未必会提升性能，因为当子程序模块未执行结束时，主程序模块只能处于等待状态。
这说明将应用程序划分层次，会带来其执行速度上的一些损失。
但从团队开发效率角度上来讲却可以感受到大不相同的效果。
需要说明一下，三层结构不是.NET的专利，也不是专门用在数据库上的技术。
它是一种更加普适的架构设计理念。
此种架构要在数据库设计上注意表之间的关系，尽力满足主与子的关系。
在功能上对用户要有一定的限制，不要表现在对于子表的删除操作一定要慎重，以免造成主表与子表的数据在逻辑上出现的主表的外键在子表中没有相对应的值。
∙对于表的综合查询方法是：先对主表查询，调用主表所对应的DL。
再根据主表的记录分别对每一个子表进行查询。
将自表的查询结果添加的主表后，形成一个大的查询集合。
对于表的操作（增删改）：此时只对主表进行操作，调用主表对应的DL中的操作方法。
RL层是逻辑判断层，主要是对页面上传入的数据进行逻辑判断。
RL层之上就是UI ∙如何建立一个三层体系结构解决方案新建一个空白解决方案。
然后：“添加”－“新建项目”－“其他项目”－“企业级模版项目”－“C#生成块”－“数据访问”（数据层，下简称D层）“添加”－“新建项目”－“其他项目”－“企业级模版项目”－“C#生成块”－“业务规则”（业务层，下简称C层）“添加”－“新建项目”－“其他项目”－“企业级模版项目”－“C#生成块”－“Web用户界面”（界面层，下简称U层）右键点“解决方案”－“项目依赖项”，设置U依赖于D、C，C依赖于D。
对U添加引用D、C，对C添加引用D。
到此为止，一个三层的架子建立起来了。
我上面说的很具体很“傻瓜”，知道的人觉得我废话，其实我这段时间很强烈的感觉到非常多的人其实对这个简单的过程完全不了解。
虽然不反对建2个“空项目”和1个“Asp net Web应用程序项目”也可以作为3层的框架，而且相当多的人认为其实这些“企业级模板项目”其实就是个空项目，这是一个误区。
没错，企业级模板项目你从解决方案资源管理器里看它是个什么也没有的，但是你可以用记事本打开项目文件，看见不同了吧？？有些东西在背后，你是看不见的，不过系统已经做好了。
也就是说，如果你在C层里的某个类里“using System Data SqlClineit”，或者使用一个SqlConnection对象，编译时候不会出错，但是会在“任务列表”里生成一些“策略警告”，警告你在C层里不要放应该放在D层的东西（虽然就程序来说没错，但是可读性可维护性就打了折扣）而这种功能，空项目是无法給你的。