学ASP.NET都知道它的最经典的架构是三层架构,也是目前应用得最广泛的一种架构.以前说起三层架构大家都知道MVC架构,这是html开发中用得比较多的，现在AJAX主要就是用这种架构。大家ASP.NET的三层是指数据访问层,业务逻辑层和表示层,而且都知道数据访问层是用来访问数据的,业务逻辑层是用来处理一些系统的业务逻辑的,表示层就是把内容呈现出来给用户，与用户进行交互的。划分三层的好处就是每一层都是独立的，修改其中一层一般不会影响其他层的代码，这样就大大的方便了日后的维护和升级。它最大的缺点是架构和编码都比较复杂，而且对性能的提高没有任何帮助，反而还可能会降低执行效率。
有时候真的觉得“三层”编起来挺麻烦的，在ASP.NET 2.0里,访问数据和显示出来只要拖两个控件就可以了(AccessDataSource/SQLDatasource和GridView)，几分钟一个页面就出来了，而且还具备了修改中，删除，分页，排序等功能。而用三层架构就麻烦多了，先要写数据访问层的代码，接着写业务逻辑层的代码(要调用数据层的方法)，最后才是表示层，也就是页面的设计，还有调用业务逻辑层的代码读取数据。(注意：表示层是绝对不会访问数据层的内容，只能通过业务层。业务层在这里是连接它们的桥梁。所以说业务层是最重要的一层)既然这样为什么还要用三层呢?前面提到的一层架构的一个很大的问题就是前台和后台代码没有很好的分开，不利于分工，第二，不利于日后的维护和升级。如果是个人主页或者是一些一个人完成的小系统用一层还是挺方面的。如果是一些比较大的系统，特别是企业级的应用，就非用三层甚至n层不可了。一般三层就很够了，再划分更多只会增加设计和编码的难度。
那到底怎么去分层呢?怎么样分层就符合三层架构原则呢?这是很多刚入门的人经常问的问题。我翻了很多本案例书，可惜很多都是一层或者是两层架构的，绝少三层的。后来研究了petshop4.0和下了一些国外的资料来看才开始对如何分层有点了解。我总结了一下主要有以下三种分层方式：
一：数据层不包含任何代码，只有数据库，还有相关的存储过程。
这种模式下，数据层看起来就变得很简单了。只包含你建立的数据库，和一些存储过程(注意是存储过程)。其实这些存储过程的建立也是相当复杂的(我以后会专门写一篇这方面的文章)，因为它们可以完成除数据访问外的其他一些很强大的功能，如分页，实现搜索算法等。数据访问的逻辑就都放在业务层，当然业务层还包含其他一些逻辑代码。我们来看一个示例，假设数据库里有一个表BOOKS(书)，建立一个存储过程GetAllBooks，用来读取书的信息，这样在业务层里编一个方法GetBookS()和一个公用数据库访问类，GetBooks()就通过数据库访问类打开连接，执行在存储过程，返回数据(返回类型可以是DataTable,DataSet,DataReader或者实体类)。业务层单独编译成一个或者几个DLL文件。接着就是表示层了，表示层通过调用GetBookS()返回数据绑定在相关的控件里。务层的方法都是在表示层调用。一般来说book.aspx和book.aspx.cs都是表示层的内容。所有前台的设计，相关控件，数据缓存都是属于表示层。
二：数据层还包含所有公共数据访问代码。
这种模式和前一种差别不大，主要是把数据访问代码六到数据层。这样可以很方面实现对多数据库的支持。业务逻辑层直接调用数据层的相关访问数据的代码，完全不必了解底层是什么数据库。其他和前一种没什么分别。
三：所有数据读取都放在数据层。
这种模式下像前面所述的GetBooks()方法都是放在数据层，在业务层再定义一个GetBookS()方法以供表示层调用。这种模式下业务层不但不必了解底层是什么数据库，而且连数据库的结构都不必了解了。这可以说是最标准的三层架构了，在Microsoft的PetShop 4.0里就是用这种模式。
以上就是我总结的一些内容，可能不是很准确，请大家多多指教。