我也来讲讲我对asp.net(C#)开发中的分层的理解吧.

从一开始接触asp.net到现在算来也有几个年头了，从学校中老师就有教过基础了，不过都是范范！压根不知道分层的概念，后来值到去年在公司有时候向他们学习C#.net,然后他们问他们三层结构怎么做，就这样一步一步，我渐渐地学会了用c#.net。(幸凡学习网就是一个很好的实例)！

刚学会我就把我的个人网改成.net版的了，当时我觉得分层也没有什么效果啊，但因为当时没有做过什么项目，看到别人对分层的讨论总是知之然而不知其所以然。后来自己尝试用分层做了一个企业网站的项目，由于项目并不大，并且所有的前后 台代码均为本人独自完成，老实说，并没有感觉到分层的好处。

最近几年的.net项目开发中，大部分也都是一个人在负责分层开发中的多种角色（数据库访问、业务编辑处理、前台表现及JS、JQUERY、 AJAX等），另外由于大部分都是一些不太复杂企业网站项目，所以一直没有分层。比如开始一个新的项目，如果其他项目已经实现了该功能，则直接把文件 copy过来，表名一改就可以用了。对于有类似功能但不完全对应上的，拿过来稍加修改也OK了。除非一点复用可能也没有的功能模块，才可能去开发。这样经 过几年积累，我可以毫不夸张的说，一般的企业网站，利用手头的代码，有个一两个小时绝对能够搞定，从这点来说，我个人并没有觉得分层有什么太多的好处，因 为如果一开始就采用分层开发，一方面分层开发本来在层之间传递数据的效果相对直接在aspx.cs中访问数据库而言，我认为肯定是慢的。另一方面，如果涉 及到小的字段修改，如果采用分层开发，那么我就要把涉及到的每个层都修改一遍，而实际对于小项目而言，如果不分层的话，往往某个字段只需修改两处即可。 （前台一次，后台一次）

那么，分层究竟有没有好处呢，网上对分层的讨论始终也没有停止过，优势劣势各有，大家各执一词。从我个人而言，虽然实际应用中分层的时候并不多，但 我并不否定分层。最近要开始一个大项目，也在网上查到了好多关于分层的资料。对于分层的好处，我觉得主要体现在以下几个方面：利于团队开发、团中的各个成 员职责分工明确，各司其职即可，另外有利于系统以后的扩展，如BS转CS，SQLSERVER转ORICAL等，至于后期的容易维护，目前还没有太深的体 会。

综上所述，我认为小项目没有必要分层，小项目的分层说俗一点，完全是脱了裤子放屁，找费事。小项目做完了就是做完了，做为客户来说，懂网站的都不 多，更有谁会去想把一个小项目改来改去的，今天BS，明天非要弄个桌面程序试试呢。对于大项目而言，我觉得还是有必要分层的，即便开发人员不多，甚至一个 人去做的话，也还是有必要分层的。分层之后，可以把思路集中在考虑某个层上。不过话又说回来，大项目的分层，我想每个公司之间或者每个人之间的分层定位也 不会分的那么特别清楚。

从CSDN上看到一篇贴子，其中有对于分层的举例说明，个人觉得还是非常浅显易懂的，一并贴上。

三层的理解：
  1、UI层：我说的这个UI层可能包含了很多的概念，除了大家都知道的window form和web form，它还包含了那些可能没有用户界面的用户接口，像window service，web service以及.Net remoting service等的入口，它们都可以看作UI层，而UI层应该只和业务逻辑层发生关系。有些系统尽管划分了层次，但却将部分的业务逻辑放在UI层，这就增 加了UI层和业务逻辑层的耦合度，不利于UI层的增加或变换，因为如果需要再增加另外的一个UI层，而新增加的层中又包含了原有UI层的部分功能，这时新 的UI层不得不再一次实现同样的功能，如果已实现的功能不符合要求，需要修改时，又不得不在已实现了的多个UI层中进行改动，这样不但增加了工作量，而且 增加了出错的可能性。 
  2、业务逻辑层：所有的业务逻辑处理的集中地，它为UI层提供服务。比如一个购物系统，当客户下了订单时，一般应该做这些事情：1、检查提交的数据的合法 性；2、验证客户信息；3、检查商品信息，比如商品是否存在，是否有足够的库存等；4、提交订单。这四步对于UI层来讲是透明的，就是说UI层只调用业务 逻辑层的一个相应的方法，而不是亲自完成这四步功能，因为这四个步骤实现了一个完整的业务逻辑，它们不可以分开。如果需要公开一个Web Service，供客户提交订单，Web Service的实现也只是简单的调用业务逻辑层的一个相应的方法。 
  3、数据（库）层：这一层才真正的实现了数据的存取，它为业务逻辑层提供服务。在这一层上不需要关注业务逻辑，只是存取数据。对于确定只用一种数据存储方 式来讲，这些就足够了。但在一个分布式的系统中，这种简单的实现是不够的，因供存取数据的不一定来自数据库，也可能来自其他数据文件，比如XML、 Excel等，不同的数据库之间也有很大的差异，这些异构的数据对业务逻辑层来讲都是透明的，业务逻辑层没必要了解数据存取的细节。那么如何才能实现这种 结构？通常的办法是为数据（库）层提供一个接口，业务逻辑层只是调用接口所约定的方法，这样通过接口就可以实现很多异构数据的存取了。

三层的好处很多：  
  比如具有灵活性，可以随意调整组件的位置和服务器的位置，可以增加和修改各个组件，更主要的是具有了商业逻辑的灵活性，因为中间层的商业逻辑层负责商业逻辑。  
  比如说容易更新，不用重新编译整个工程就可以更新功能，替换一个组件不会扩大影响到整个工程。  
  比如说容易维护，各层意义明确，不会出现商业逻辑和各种访问控制混合在一起的情况，而且分层的好处是，各层可以使用不同的配置，各个服务器的维护也变得简单。  
  比如说有天生的网络化，只要配置好一个外部环境，各个组件运行时不会注意到自己访问的是网络资源还是本地资源，这种分布式的好处对于一个企业来说是急需的。  

分层，无非就是松耦合，便于维护，也便于理解

没错，你们一个人做一个模块，但是如果再给你一个模块，那么连接数据库的那些代码你是不是又要重写一遍？
或者说，你要再拷贝过来一份，如果出了Bug，你是不是10个模块都要去修改？

对数据库的访问可以单独做成一个项目，然后引用到你做的所有模块中去
这个是我认为的分出数据层的意义

结语：

分层，无非就是松耦合，便于维护，也便于理解