Why we use it? 为什么要用三层
从行为型模式命令模式引发的对三层的思考。
记得《大话设计模式》中对命令模式的讲解。烧烤摊和烧烤店之间的区别。
由于客户和烤羊肉串老板的“紧耦合”所以容易出错，容易混乱，也容易挑剔。
这其实就是“行为请求者”与“行为实现者”的紧耦合。
对请求排队或记录请求日志，以及支持可撤销的操作等行为时，“行为请求者”与“行为实现者”的紧耦合是不太适合的。
作为客户不用去认识烤肉者是谁，连他的面都不用见到，我们只需要给接待我们的服务员说我们要什么就可以了。他可以记录我们的请求，然后再由他去让烤肉师傅做。
烤肉师傅也不用知道具体的客户是谁，只要知道客户详细的要求就行了，然后根据先后顺序操作，不会混乱也不会遗忘。
而烧烤师傅取材料进行加工的时候又可以用构造型模型，如：工厂模式。
三层模型提高了程序的扩展性，可维护性，降低了模块之间的耦合。
对于使用用户较少的程序来说，三层并没有什么必要。
但是对于，用户较多，功能复杂的程序软件来说，进行功能划分和提高资源使用效率和通信效率是很重要的。三层只是从一跨到了三，其中还有可以细化的部分
之后我们还要学习七层以提高用户使用软件的体验。
What : 三层的机制是怎么样的？
所谓三层体系结构，是在客户端与数据库之间加入了一个中间层，也叫组件层。
这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
数据库原理中有提到在用户（或应用程序）到数据库之间，DB的数据结构有三层模式，两层映像。（ 外模式 / 逻辑模式 / 内模式 ）
外模式是用于与数据库系统的接口，是用户用到的那部分数据的描述。外模式由若干个外部记录类型组成。
逻辑模式是数据库中全部数据的整体逻辑结构的描述。它由若干个逻辑记录类型或，还包含记录间联系 数据的完备性安全性等要求。
内模式是数据库在物理存储方面的描述，定义所有内部记录类型 / 索引和文件的组织方式，以及数据控制方面的细节。
类比可知
各层的作用
表示层（UI）：
展现给用户的界面。
（例如： 顾客看到的菜单，体现了这个餐厅可以满足用户哪些需求）
业务逻辑层（BLL）:
对数据层的操作和业务的处理。接受用户的指令或者数据输入，提交给应用层做处理，同时负责将业务逻辑层的处理结果显示给用户。
（例如： 服务员接受顾客的订单，并反馈给客户餐厅是否能够满足客户的订单要求；将客户的订单下达给厨师进行按需烹饪；当菜制作完毕，由服务员将菜端给下单的客户，并接受客户的反馈，用餐评价和收钱。）
数据层（DAL）:
直接操纵数据库，主要是增删改查的功能。存储数据的数据库服务器和处理数据和缓存数据的组件。组件将大量使用的数据放入系统的缓存库，以提高数据访问和处理的效率。
（例如：厨师在厨房直接磨刀霍霍向猪羊，对各式各样的食材进行各种精细的操作。）
优点
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
缺点：
1、降低了系统的性能。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
How : 我们如何搭建和实现三层？
小编正在学习中，为给各位带来启发和思想上的共鸣，定个小目标三天完结。
记得回访哈~