ASP.NET的三层架构--艺术的美

1. 主体层，从下至上分别为：

• 数据访问层（Data access layer）DAL
  执行对数据的增删改查和传递工作
• 业务逻辑层/领域层（Business Logic Layer）BLL
  对数据业务的逻辑处理
• 界面层（User Interface layer）UIL
  显示数据和接受并传输用户的输入数据

2. 辅助层

• 数据传输对象（Data Transfer Object）DTO
  在客户端和服务器端之间高效、安全地进行数据传输

各层的作用

目的 ：“高内聚，低耦合”的思想
优点：降低层与层之间的依赖
缺点：系统架构复杂，不适合小型项目

1. 数据访问层：
   主要是对非原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据库的操作，而不是数据，具体为业务逻辑层或表示层提供数据服务。
2. 业务逻辑层：
   主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。
3. 界面层：
   主要表示WEB方式，也可以表示成WINFORM方式，WEB方式也可以表现成：aspx，如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都能完善地提供服务。
4. 数据传输对象
   DTO是面向界面UI，是通过UI的需求来定义的。通过DTO我们实现了表现层与Model之间的解耦，表现层不引用Model，如果开发过程中我们的模型改变了，而界面没变，我们就只需要改Model而不需要去改表现层中的东西。DTO的存在就是为了帮助我们减少客户端请求而降低服务器压力，提升效率。使用DTO后我们可以灵活定义数据模型，同时将数据模型和逻辑剥离

规则

1. 最核心的模块规则，表现层只是外壳作用，不能包含任何BizLogic的处理过程。
2. 各层次模块设计时应该从业务逻辑层出发，而不是开始于表现层.。业务逻辑层在API上应该实现所有BizLogic，以面向对象的方式。
3. 不论数据层是一个简单的SqlHelper，还是带有Mapping的Classes，应该保证其与抽象的系统层无关。
4. 不管使用COM+(EnterpriseService)，还是Remoting，还是WebService之类的远程对象技术，不管部署是否在服务器上，在起码在设计时必须要考虑多台服务器通过负载均衡作集群。
   综上，考虑一个项目是否符合应用三层或多层设计时，必须要考虑是否真正符合项目的需求。