❶ 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服务放到别处。
❷ asp.net三层架构中，是不是不需要用到数据库的都可以在表示层直接写代码还是说表示层都是要调用业务层的
不用到数据库,就没有数据访问层,那你建的项目就不是三层架构.如果你使用了三层的话,表示层还是要调用业务层的.
使用三层是为了“高内聚，低耦合”的思想,使得开发人员的分工更加明确,降低层与层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。
表示层:也就是界面层,给用户看到
业务层:对数据业务逻辑处理
数据访问层:对数据的增、删、改、查等.
用户提交了一个请求,先传递到业务层,业务层进行处理,再转到数据访问层,数据访问层,在对数据库进行相关的操作,得到一个结果,再传到业务层,业务层处理完了之后,返回给界面层,最终响应给了用户.
❸ 关于ASP.NET三层架构的问题
控件绑定了数据源 不一定违背三层架构，关键是你的数据源是如何得到的。
1、你指的数据源就是数据库里的某个表或某些数据。
2、你指的数据源是通过业务逻辑层取得的对象列表。
前者这样处理没有使用三层架构，后者则使用了架构。
如果你不使用架构，那么如果将来你的系统业务需求发生变更，可能会导致你重新根据条件绑定数据源，如果用了架构你只需要修改业务逻辑层相应的方法。
分层架构的优点就是便于维护，如果你都是以绑定数据源的方式实现，那么一个业务发生变化，可能你要修改很多个绑定的控件。
❹ asp.net中要用到三层架构吗用的好处是什么
不过,我觉得任何事情都不要这么绝对,小项目你分那么清楚干什么?怎么方便怎么写就对了
中小型的,就考虑一下分点层出来,主要还是方便维护~~~
中型项目要在项目开始前有一个比较好的规划,如何划分层次结构,但是还不至于必须一个表一个类,多表关联可以搞死你~~~
大型项目的话,架构就比较复杂了,光数据访问层就可以分为至少两部分,而且一般的层次结构几乎无法适应所有的CASE,这个时候就要用一些办法了,当然,这些办法主要还是那些模式,这样可以组合出适合你的项目的层次结构出来.(说白了,MVC不就是这样的吗?)
也不要总是三层三层的,有的时候3层多余,有的时候明显不够.比如说,我们现在正在研发的一个数据平台,初步划分为6层,在评审的时候已经发现不足了,还得再继续分下去……
综上所述,不要太过绝对,不分层的小软件不一定不是好软件(不过只要是软件,总能分点层出来),分层的也不一定就是什么好玩意儿，“合适的”才是“最好的”～～～
❺ .net网站是不是说用三层架构做的比不用三层架构的好
分层是趋势，但小项目上优势体现不出来。所以当是学习。架构的学习是很有必要的。
❻ .net Web网站不使用三层架构,MVC模式（啥都没用）的弊端
耦合度太高, 不利于代码维护和阅读
不过小项目的话不要紧, 分层反而变得很麻烦