ASP.NET三层架构

为何使用N层架构？

因为每一层都可以在仅仅更改很少量的代码后，就能放到物理上不同的服务器上使用，因此结构灵活而且性能更佳。此外，每层做些什么其它层是完全看不到的，因此更改、更新某层，都不再需要重新编译或者更改全部的层了。这是个很强大的功能。例如，如果把数据访问代码与业务逻辑层分离，当数据库服务器更改后，你只需要更改数据访问的代码，因为业务逻辑层是不变的，因此不需要更改或者重新编译业务逻辑层。

一个N层的应用程序通常有三层：表现层、业务层和数据层。下面让我们看看每层都做些什么。

表现层（Presentation Layer）

表现层用于用户接口的展示，以及用业务层的类和对象来“驱动”这些接口。

在ASP.NET中，该层包括aspx页面、用户控制、服务器控制以及某些与安全相关的类和对象。

业务层（Business Tier）

业务层用于访问数据层，从数据层取数据、修改数据以及删除数据，并将结果返回给表现层。

在ASP.NET中，该层包括使用SqlClient或OleDb从SQL Server或Access数据库取数据、更新数据及删除数据，并把取得的数据放到DataReader或DataSet中返回给表现层。返回的数据也许只有一个整型数字，比如一个表的行记录数目，但这也要用数据层的数据进行计算。

BLL和DAL

通常该层被划分成两个子层：业务逻辑层（Business Logic Layer，BLL）和数据访问层（Data Access Layers，DAL）。业务逻辑层在数据访问层之上，也就是说BLL调用DAL的类和对象。DAL访问数据并将其转给BLL。

在ASP.NET中，该层可以用SqlClient或OleDb从SQL Server或Access数据库取数据，把数据通过DataSet 或DataReader的形式给BLL，BLL处理数据给表现层。有的时候，例如直接把DataSet 或DataReader送给表现层的时候，BLL是一个透明层。

数据层（Data Tier）

数据层是数据库或者数据源。在.NET中，通常它是一个SQL Server或Access数据库，但不仅限于此两种形式，它还可能是Oracle，mySQL，甚至是XML。

逻辑层VS（分布式）物理层

人们容易将这两个概念搞混。我们说逻辑层是把层按类的集合来划分，而这些层都在同一台个服务器上。（分布式）物理层是指类的集合在不同的服务器上，用附加的代码来处理层间的通信，比如remoting和web服务。

决定如何划分你的层（是物理的还是不是物理的）是非常重要的。在划分时应考虑下面因素：

1、注意如果划分成物理层，你的应用程序的速度会因为不同服务器在网络中通信的延迟而减慢。所以，如果你决定用物理层，请确保获得性能的提升大于性能的降低。

2、按照n层架构设计你的应用程序。

3、部署以及维护物理分布式的应用程序的成本是很高的。你首先需要不止一台服务器，你还需要网络硬件来连接这些服务器。在这种情况下，部署应用变得更加复杂！因此这样做之前请确定这样做是否值得。

另外还要注意，你的应用程序的每层都做何使用。你也许因为运行的多个服务都需要某一层而把该层放到别台服务器上。例如，你也许会因为给不同的用户定制不同的表现层，而将业务逻辑层放于别处；你也许会因为还有其它的应用访问同一个数据库，而把SQL server服务放到别处。

三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。
1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。
业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一书中，将整个架构分为三个主要的层：表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans，对业务逻辑层作了更细致地划分，细分为应用层与领域层，通过分层进一步将领域逻辑与领域逻辑的解决方案分离。
业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。
数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。
简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。

其实很简单。。。你既然是用ado.net 那么你现在肯定在做winform了？
而不是web开发 对吗？ 这里我先简单的给你说一下：
你建的哪个winform 页面。。也就是框体 就是 页面显示层(UI层)
你的所有操作数据库的方法 全部放到一个类库中去就是数据访问层。(DAL)
你页面需要用的方法全部到业务逻辑层(BLL)中去找。。。BLL层去调用DAL里面的所有方法 以备UI层使用 就ok了。。。说的不太明白。。可以hi我。。。我这里winform和web的项目

楼上的就行。
简单的说就是一个界面层，一个业务逻辑层，一个数据访问层，是个上下级关系
界面层调用业务层，业务层再调用数据访问层来取得数据，数据访问层把数据一层一层的向上传递到界面层来做数据展示。
关键就是各层独立

bll是MVC中的C层，业务层
DAL和Model都是M层
model层是与数据表的一一对应（也可增加检索字段、外观字段等）
Dal是与数据库访问的
bll调用dal中的方法
你现在觉得不需要这么多层，是因为你的业务逻辑还太少，等你业务逻辑多了，你就会发现分层的好处了。