1，
三层架构
UI即UserInterface /表示层(USL - User Show Layer)
业务逻辑层（Business Logic Layer）
DAL为数据访问层(Data Access Layer)
三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。
1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、查找等。
在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。 微软 推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
三层结构原理：
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，以及对象实体的持久化。
编辑本段优缺点
优点
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
6、结构更加的明确
7、在后期维护的时候，极大地降低了维护成本和维护时间
缺点
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3、增加了开发成本。
编辑本段规则
三层结构的程序不是说把项目分成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就足够了，完全没必要作的这么复杂. 而 多层结构，是用于解决真正复杂的项目需求的。
编辑本段与MVC的区别
MVC（模型Model-视图View-控制器Controller）是一种设计模式，我们可以用它来创建在域对象和UI表示层对象之间的区分。
同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。
在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是 三层架构中Model的概念与MVC中Model的概念是不一样的，“ 三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。
model的字段封装 是数据载体，不是一层。
UI BLL DAL Model
UI 界面层 页面
BLL 业务逻辑层 逻辑处理
DAL 数据访问 对数据的增删查改
Model 模型层 封装字段
UI 界面层 页面
BLL 业务逻辑层 逻辑处理
DAL 数据访问 对数据的增删查改
Model 模型层 封装字段
--(转)分层并不重要， OO 才是最重要滴 ！！！
Model 层，一些只有属性、字段而无方法滴类，基本上都是数据库表直接映射而来滴，
虽然用到了 class 关键字，但它们不是类，只是一些数据表滴变体而已，形象一些也可称为数据傀儡，
只能任人摆布，结论 Model 层是一些残疾类滴集合，没有丝毫 OO 滴思想；
BLL 层，一些静态类或者一些提供静态方法（增删改查）滴类，这些类只有方法而无属性、字段，
同样它们也不是类，只是一些加工器而已，OO 思想更与 BLL 毫无关系！
虽然用到了 class 关键字，但它们不是类，只是一些数据表滴变体而已，形象一些也可称为数据傀儡，
只能任人摆布，结论 Model 层是一些残疾类滴集合，没有丝毫 OO 滴思想；
BLL 层，一些静态类或者一些提供静态方法（增删改查）滴类，这些类只有方法而无属性、字段，
同样它们也不是类，只是一些加工器而已，OO 思想更与 BLL 毫无关系！
从上至下依次为，表示层、业务实体层、数据访问层！
表示层，用于展示、收集数据，与 业务实体层 交互；
业务实体层，暂时跳过；
数据访问层，访问数据源，填充业务实体！
业务实体层，暂时跳过；
数据访问层，访问数据源，填充业务实体！
关键就是业务实体，业务实体 = Model + BLL，属性加方法才是对象，因此将 Model 与 BLL 合并
就得到了真正滴业务实体，为了更好滴适应业务需求，业务实体之间可以相互组合，例如：A 班级下可以有
本班学员列表，即 classA.StudentList；业务实体还可以扩展自己滴成员方法，例如：A 班级下找出所有姓
赵滴同学，即 classA.FindAllByLastName("赵")；班级类上还有静态方法，例如：新增 A 班级，
即 Class.Add(classA)，删除 A 班级，即 Class.Remove(classA)等等！
就得到了真正滴业务实体，为了更好滴适应业务需求，业务实体之间可以相互组合，例如：A 班级下可以有
本班学员列表，即 classA.StudentList；业务实体还可以扩展自己滴成员方法，例如：A 班级下找出所有姓
赵滴同学，即 classA.FindAllByLastName("赵")；班级类上还有静态方法，例如：新增 A 班级，
即 Class.Add(classA)，删除 A 班级，即 Class.Remove(classA)等等！
业务实体主要定义了与本实体相关的属性和方法，至于多对象之间的复杂交互应添加一个新层——业务外观层，
而业务外观层多是一些静态类，为表示层提供一些功能！
而业务外观层多是一些静态类，为表示层提供一些功能！
复杂三层就变为： 表示层（WebForm or WinForm ...）->业务实体层（三层架构的核心）->数据访问层（SqlServer or Excel or XML ...）
实体类-Model 实质：实体类就是在完成数据库与实体类对应的功能，一个类是一张表，一个属性是一个字段！
三层中的最底层-数据访问层(DAL) 这一层要引用实体类和对Configuration的引用
实质：就是对数据库中的内容的增，删，改，查
三层中的桥梁-业务逻辑层BLL 这一层需要引用实体类和数据访问层
三层中的顶层-表现层UI 这一层要引用实体类和业务逻辑层
2,类成员：属性 方法 事件