编程路上三层始出现

    三层架构：三层是一个笼统的概念，是在逻辑上的划分，我们在设计复杂的程序时，为了使我们维护更加的简单，提出的一种概念。它分为三层，两个直接，一个中转。只要逻辑够复杂就把代码放到B层，只要数据访问了就把代码放到D层。U层做的好看一点，让人用起来要舒服。

    U层：即用户界面层，直接与用户打交道的。在代码中没有商业业务逻辑，没有或有少量的SQL，存储过程语句。而且这些语句用不着修改。

    B层：即业务逻辑层，处理业务上的复杂逻辑，主要进行业务上的逻辑判断。是整个系统的核心，和我们的需求是直接相关的。它连接了U层和D层。在设计系统时，我们就是根据这块来进行设计的。

    D层：即数据访问层，注意它是数据访问，而不是数据库本身。它是直接对数据库进行增删改查的。把结果返给B层。

    我对三层架构优点的理解：分工合作，开发效率高，每个人可以专注搞自己的一层；由于每层相互独立，所以只要接口搭配好了，每层都可以替换。相比VB版的代码，三层的代码要简单，结构清晰；每层代码都可以复用，典型面向对象的特点。

    缺点：三层相互传递信息，降低了系统的性能，不过对机房来说根本看不出来。导致级联的修改，也就是说，给U层添加一个功能，相应的B层和D层也要修改。

   了解三层的大概了，那么怎么着才是三层呢？很简单，三层的优点做到了，那就是三层喽。简单说一下：

U层只有少量的或没有SQL语句和存储过程，且这些语句都不会修改；要求D层可以移植到其他的项目中；各层的模块可以在其它服务器上运行。U层只能作为一个外壳，不能包含BizLogic（商务逻辑）的处理过程。

设计时从B层出发，不是从U层出发，B层在API（应用程序）上应该实现所有BizLogic；D层是简单的SqlHelper（封装好的数据库操纵组件）也好，还是带有Mappitng过的Clases（ORM对象关系映射，和数据库有关）也好，应该在一定的抽象程度上做到系统无关；不管使用COM+（可能是面向组件编程）还是Remoting（一种分散式程序设计）还是WebService（一种分散式程序设计）之类的远程技术，不管部署的时候是不是真的分别部署到不同的服务器上，最起码在设计的时候要做这样的考虑，更远的，考虑多台服务器通过负载均衡做集群。感觉系统特别大了，三层正好分担系统的压力。

      还有另一个问题：说是三层，可明明在敲代码有个实体层，那这是个什么东西类。看完三层的一大堆后，我的理解时：它不属于三层，可没了它我们在设计时虽然可以实现，但是忒麻烦。可以根据代码可以观察下实体层。它里面就是包含了大量的信息，基本没有什么方法实现；它在三层交换信息时起到了作用；它和数据库的设计比较契合。所以说实体层不属于三层，它压根就没有什么功能实现，换言之没了你这个系统照样存在。那为什么又麻烦呢？在三层相互交换信息时，我们需要参数，假设你传递的是参数，那么整个系统那么大，大量的参数就把你搞晕了。另一个就是传参的个数了，一个两个，还好说，要是一大堆呢。所以说没了实体层就是麻烦啊，所以感叹前辈的高明啊，为我们的设计之路铺好了那么多。实体层：对那么多参数的分类，把参数封装到一块，用到哪个参数，再把它给点出来。

      上面我提到了三层架构了，其实我压根就不知道什么是架构，架构啥玩意呢。一般人还真搞不懂。考虑到读者，也考虑到咱的文采请看下篇吧。