N层架构

层次划分：

　　目前，典型的分层架构是三层架构，即自底向上依次是数据访问层、业务逻辑层和表示层。

　　这种经典架构经历了时间的考验和实践的多次检验，被认为是合理、有效的分层设计，所以，在本文中，将沿袭这种经典架构，使用数据访问层、业务逻辑层和表示层的三层架构体系。

　　职责划分：

　　目前，在典型的三层架构中，对层次各自的职责划分并没有一个统一的规范，综合现有的成功实践和.NET平台的特殊性，在本文中将三层架构的职责划分如下：

　　数据访问层——负责与数据源的交互，即数据的插入、删除、修改以及从数据库中读出数据等操作。对数据的正确性和有效性不负责，对数据的用途不了解，不负担任何业务逻辑。

　　业务逻辑层——负责系统领域业务的处理，负责逻辑性数据的生成、处理及转换。对流入的逻辑性数据的正确性及有效性负责，对流出的逻辑性数据及用户性数据不负责，对数据的呈现样式不负责。

　　表示层——负责接收用户的输入、将输出呈现给用户以及访问安全性验证。对流入的数据的正确性和有效性负责，对呈现样式负责，对流出的数据正确性不负责，但负责在数据不正确时给出相应的异常信息。

理解三层结构

　　我们用三层结构主要是使项目结构更清楚，分工更明确，有利于后期的维护和升级．

　　三层结构包含:表示层(USL),业务逻辑层(BLL),数据访问层(DAL)

　　1：数据访问层:主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不

　　是指原始数据，也就是说，是对数据的操作，而不是数据库,具体为业务逻辑层或表示层提供数据服务．

　　2：业务逻辑层:主要是针对具体的问题的操作，也可以理解成对数据层的操作,对数据业务逻

　　辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。

　　3：表示层:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成

　　:aspx, 如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地

　　提供服务。

结构说明

　　完善的三层结构的要求是:修改表现层而不用修改逻辑层,修改逻辑层而不用修改数据层

　　.否则你的应用是不是 多层结构,或者说是层结构的划分和组织上是不是有问题就很难说.

　　不同的应用有不同的理解，这是一个概念的问题．

　　以下是一些个人感想

　　是的,这是一个比较抽象的问题,但是看看应能明白了.

　　业务逻辑层,就是把你的代码中大量出现的组合成一个函数,以后当你需要使用这些代码时,直接调用函数即可.比如.NET中有大量连接数据库的代码(基本上都差不多),我们就可以直接用一个用户控件来定义一下这样代码.以后当我们要连接数据库时,直接调用这些函数就可以了.这些东西就可以叫做逻辑或者 中间件.以后我们修改数据库的连接代码时,直接修改这些用户控件就可以了.

　　三层结构不是.NET的专利，也不是专门用在数据库上的技术。它是一种更加普适的架构设计理念。数据-逻辑-界面。在实际应用中还会根据需要多出传递数据的层，接口层等等。

编辑本段优缺点

优点

　　1、开发人员可以只关注整个结构中的其中某一层；

　　2、可以很容易的用新的实现来替换原有层次的实现；

　　3、可以降低层与层之间的依赖；

　　4、有利于标准化；

　　5、利于各层逻辑的复用。

缺点

　　有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

编辑本段相关概念

　　1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。

　　2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。

　　3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。