初览三层（理论篇）

       闻听三层，在学习之前我对它听说，具体是什么东西还不知道，脑海里无数次想象着三层的模样，带着它是什么、它能做什么、它的作用是什么这三个问题我开始进入三层的世界。

     一、 概述

      这里所说的三层指的是逻辑上的三层结构。

      这三层都包括：UI（显示层）、BLL（业务逻辑层）、DAL（数据访问层），这三层的主要分工如图：

      1. UI只负责显示和采集用户操作，不包含任何的业务相关的逻辑处理；

      2. BLL负责处理业务逻辑。通过获取UI传来的操作指令，决定执行业务逻辑，在需要访问数据源的时候直接交给DAL处理。处理完成后，返回必要数据给UI；

      3. DAL只提供基本的数据访问，不包含任何业务相关的逻辑处理。

      二、各个层之间的引用关系

      UI -> BLL -> DAL，这三层分别在不同的程序集中。

    解析：1.DAL所在程序集不引用BLL和UI

                 2.BLL需要引用DAL

                 3.UI直接引用BLL，可能会间接引用DAL

      三层结构很清晰，有很明确的分工，而且相对独立，但在实现关于三层的登录小例子的时候，又多了一个实体层，即Model层，我觉得它只是数据库中的表变相为实体，相当于一个临时容器，为了存取数据方便而已，它与每个层都有关系。怪不得王继斌老师将它形容为“上蹿下蹦”，上蹿蹿到UI层，下蹦蹦到DAL，专门用来放数据模型的。是为了封装数据，然后在三层之间能够传输数据，是独立于其他三个层次，它不会引用任何一个程序集的。

     三、 优缺点

      （1）优

      1.可降低层与层之间的依赖

      2.有利各层逻辑的复用

      3.有利于标准化

      4.安全性高，用户端只能通过业务逻辑层来访问数据库，减少入口点

      5.项目结构清楚，分工更加明确，有利后期的维护和升级

      正因为这些优点，使三层达到了解耦的目的。

      （2）缺

      1.降低了系统的性能

      2.增加了代码量和工作量

      四、什么时候使用

      当业务和数据复杂时，即既有数据访问层，又可以抽象出业务逻辑层，这时使用可以发挥出三层的优点。可以把数据访问脱离开业务单独存在，把业务脱离开UI单独存在，UI只需要呼叫业务访问层就可以实现跟用户的交互。

      五、现实生活中的三层

      三层、实体层之间的关系就像我们去食堂吃饭一样，厨师在厨房里做饭，然后服务员负责将饭菜放到我们碗中，最后学生就可以吃饭啦。其中，厨师怎么做饭的学生不知道，服务员也不知道，学生也不知道饭菜从厨师到服务员那儿需要做什么，但不管是厨师、服务员还是学生都接触到的就是饭菜。总之，厨师、服务员、学生这三者之间是没有关系的，但因学生有需要饭菜这一需求，所以饭菜让这三者之间有了联系，如下图：

      结语

      当然，三层并不是严格意义上的三层，并不是定死的三层，在进行开发的时候，可根据实际情况来使用三层，发挥三层的优点就是最好的开发。