从一开始接触asp.net到现在算来也有几个年头了，刚开始学C#的时候，压根不知道分层的概念，后来有了一些了解之后，发现大家都在谈分层，但因为当时没有做过什么项目，看到别人
对分层的讨论总是知之然而不知其所以然。后来自己尝试用分层做了一个企业网站的项目，由于项目并不大，并且所有的前后台代码均为本人独自完成，老实说，并没有感觉到分层的好处。
最近几年的.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个模块都要去修改？
对数据库的访问可以单独做成一个项目，然后引用到你做的所有模块中去
这个是我认为的分出数据层的意义
表现层和业务层分开，举个例子：工资计算，今天老板说：工资都是底薪加奖金，
好，做了个程序，10个页面都用这个公式计算，并显示工资
明天老板说，工资制度改革，改成底薪+奖金*表现的百分比
这时你所有牵涉到计算业务的地方都要改了
如果所有页面都只用于显示工资，计算放到业务层做，这样就只要改业务层关于计算的地方就好了
