asp.net从这里开始第一天------分层设计思想

      对于一个大一点的项目涉及的代码，逻辑都比较复杂，这么多内容如果提前没有详细的规划，很难在后期中进行有效的维护与管理。那么我们应该怎样规划组织我们的代码？现在最流行的方式就是分层(通常是三层)的设计思想。就一个网站而言，想想你现在看到的这个网页，这是一个界面（对于整个csdn而言这样的界面有很多可以称为界面层或显示层），而这个界面的数据都在哪里保存，不难想想当然是在数据库中存储的（动态网站开发都会用到数据库技术），数据库中的数据是如何被调出显示在界面上的，以及你看完本文留下好评(意淫)是如何保存到数据库中的，完成这些操作的代码显然和界面显示的代码实现两种不同的操作，所以这块功能一般就叫数据访问层。界面层是不是直接调用数据访问层的相关方法和数据库打交道。很遗憾答案是否定的，注意这里数据访问层仅仅是指操作数据库，不应该包括任何的逻辑判断，但如果我想对用户评论的内容进行过滤处理，比如过滤掉 狗屎，垃圾这些不健康的词汇后再把留言内容保存到数据库中，这些代码我们应该放在那里？这些代码位于界面层与数据库访问层之间被称为业务逻辑层，即业务逻辑层根据具体的业务逻辑（用户在界面的操作，比如发表评论，下一页等等）决定调用哪个及怎么样调用不同的数据库访问层方法。当然业务逻辑也可能不会调用数据访问层方法。比如仅仅想产生个验证码以在页面中显示出来。

   比如我们把一个饭店子看成一个软件，前台服务员可以看做界面层，顾客点什么饭，服务员会告诉后面的大厨做什么（根据用户操作会产生不同的业务逻辑），后面大厨要做包水饺，蒸包子（业务逻辑层要干的操作），磨面师傅在磨面时候根不需要关心磨出的面要做什么（数据访问层）

  这种分层的好处有以下几点

    1 开发人员可以只关注整个结构中的其中某一层
    2 可以很容易的使用新的实现来替换原有层次的实现
    3 可以降低层与层之间的依赖
    4 有利于标准化
    5 利于各层的逻辑复用

概括来说，分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。 一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。例如界面层人员只需考虑用户界面的体验（有一定的审美能力），操作领域的设计人员（业务逻辑层）可以仅关注业务逻辑的设计，而数据库访问层设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认，开发进度就可以迅速的提高。

松散耦合的好处是显而易见的。如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。降低层与层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。每个功能模块一旦定义好统一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。分出数据访问层就能很好的为使用不同的数据库系统进行扩展，比如针对多个数据库系统（SqlServer Access Mysql等）开发了一套系统，可能仅仅数据访问层不同，其他层的代码基本都是一样的。
分出业务逻辑层就能很好的为其他界面层使用业务进行扩展 ，比如可以开发c/s b/s两套酒店管理系统，只是界面层发生了变化而其他两层不变。

进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。 
     “金无足赤，人无完人”，分层式结构也不可避免具有一些缺陷： 
    1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
 
   2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。