三层初体验

     学习完了第一遍机房收费系统，我们就了解了高内聚，低耦合。学习完设计模式和三层，代码分层，功能分区，真正诠释了什么是高内聚，低耦合。接下来我将结合自己看过的视频，实现的代码为大家介绍一下我对三层的理解。
   早在我们实现第一遍机房收费系统时，我们知道我们写的代码大多是一层或者层层穿插，虽然那时已经有了要将代码简单归类和层的意识，但是没有细致到真正将代码分层。在第二遍机房收费系统开始前，我们学习了三层的概念。三层就像是管理我们代码的交警，让我们的代码有序起来。

   那么什么是三层呢？

   百度的解释是：三层为：界面层（User Interface layer）（简写UI）、业务逻辑层（Business Logic Layer）（简写BLL）、数据访问层（Data access layer）（简写DAL）。

   各层的作用是什么呢？

   1：数据访问层：

   主要是对非原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层提供数据服务．

   2：业务逻辑层：

   主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。

   3：界面层：

  主要表示WEB方式，也可以表示成WINFORM方式，WEB方式也可以表现成：aspx，如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都能完善地提供服务。

  我们为什么要使用三层呢？

  在文章开头，我们就说了三层是为了达到“高内聚，低耦合”效果。但前提是我们的代码很多，到了可以让我们“乱”的程度——代码耦合在一起，做出的程序是一次性的程序，不能在后期分层进行维护。。。三层就是代码中的交警，负责维护秩序。

   三层的优点如下：

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

   难道三层就没有缺点吗？增加了层的概念，层层之间引用，怎么可能没有矛盾呢！    

  缺点是：

   1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。 　 

   2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

   三层这个交警是如何指挥代码工作的呢？

   借图说话：

                                           

     我们的系统在运行时是从界面层到业务逻辑层再到数据访问层，但是在用代码实现的时候从数据库从下向上实现。

  除了BLL，DAL，UI，Model和common又是用来做什么的呢？

                                   

     Common项目中一般放的是公用文件，如数据操作类DBHelper等，被数据访问层的类调用；Modal项目中存放的是实体类，在Modal项目中，我们放置与数据库中表设计对应的实体类。这样我们就不用像敲机房收费系统时一一用fields(0-n)来对应数据库中的表，也就避免了在删除表中的字段时带来的麻烦。比如三层中UserInfo：

 

namespace Login.Model   //独立其他程序集，与数据库中表的字段一一对应{    public  class  UserInfo    {        public int ID { get;set ; }        public string UserName { get; set; }        public string Password { get; set; }        public string Email { get; set; }    }}

        
                  

   现在对三层的理解还仅仅是表层上的概念理解，如有不足，希望大家指出。