三层架构秘籍
前言
关于三层架构，你想知道的，都在这里。
目录
一、什么是三层架构
定义：
UI(表现层): 主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。
BLL:(业务逻辑层): UI层和DAL层之间的桥梁。实现业务逻辑。业务逻辑具体包含：验证、计算、业务规则等等。
DAL:(数据访问层): 与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。（当然这些操作都是基于UI层的。用户的需求反映给界面（UI），UI反映给BLL，BLL反映给DAL，DAL进行数据的操作，操作后再一一返回，直到将用户所需数据反馈给用户）
二、三层架构如何联系在一起
经典用一个厨师案例辅助理解
当你某天去饭店吃饭，服务员拿到你们的菜单，菜单要求青椒炒肉，赶巧店里没有青椒了，那么此时采购员就发挥作用了，采购员出去买青椒，交给厨师，厨师做好菜，交给服务员，服务员将菜端给我们，这就是完成了一个流程。如果当客人对菜有要求，比如说青椒炒肉我要朝五花肉，那你是不是的更新一下菜单，那么这个菜单就可以是我们的实体类，通过实体类的参数传递完成对客人要求的满足，因为客人不可能每个人都吃一样的口味，有的人要辣，有的人要甜，就是这个道理。
实体类层（Entity）：它不属于三层中的任何一层，但是它是必不可少的一层。
实体类层主要作用就是将生活中的常见事物封装称为一个类，那么我要用的时候，调用他的属性即可。
实体类在三层之间做一个传递数据的作用，比如我买一件衣服，这件衣服的价格，尺寸，材料等等都给我封装到衣服类中，我要看的时候我在UI界面能看到，搜索相关条件能搜到，并且能够购买，数据库那边也有一一对应的字段，我的一个类就可以看做是数据库中的表。
三层之间的联系主要还是看他们之间的引用，例如我们买衣服，我们在网上买衣服是不是只关心，衣服好不好看，便宜不，尺寸合身不，等等，不会去关心我买衣服是怎么操作的，以及数据是怎么来的，那么当我发送了搜寻衣服，比如搜一件男装冬天，那么请求就会发送得到业务逻辑层，逻辑层去处理我的请求，把请求发送到数据库，数据访问层找到衣服，返回衣服，衣服返回到业务逻辑层，逻辑层再做他相应的处理之后，就到了我们的电脑屏幕前面。这就是整个三层架构的联系过程，且这三者是互不干扰，存数据的只存数据，包装的就只做包装，就像工厂流水线一样，这样效率才高。
三、为什么要使用三层架构
其主要目的就是解耦，让三层之间的业务关系耦合度降低，每一层就只做自己的事情，提高效率，且就算你有一层的东西发生了变化，也不会影响整个系统的逻辑。
就比如说，厨师辞职，只要他会做菜，那老板也不用担心，服务员换掉，也无关紧要，无非就是这个厨师做菜和那个口味可能有些许不同。
当你的项目比较大，且涉及到后期的新功能添加或者后期的维护，那么三层架构不失为你的好选择。
四、三层架构与两层的区别
在开发中，三层架构代码写起来代码量也是相当大的，那么可不可以不要中间的处理层，我直接UI与数据库进行交互呢？答案当然是可以的。
两层架构一般用在小的项目，不需要后续的维护，或者说更新其他的功能的项目，直接与数据库交互就好，简化代码量。缺点就是如果某个大项目有地方需要维护，由于没有进行分层，那维护成本是相当高的。
三层：发生在哪一层的变化，只需更改该层，不需要更改整个系统。层次清晰，分工明确，每层之间耦合度低——提高了效率，适应需求变化，可维护性高，可扩展性高
那么很明显，三层架构的优势在于：
1，耦合性较低，后期维护成本低。
2，利于后期维护和增加新功能。
三层架构的劣势很明显：
1.增加了代码量和工作量，
2.可能导致级联的修改，在三层架构中，由于我们的业务逻辑是分层来做的，那么我们添加一个功能的时候，可能会涉及到修改三层中各级的功能。
3.降低了系统的性能，因为我们不仅有操作层，才能进入数据库，如果直接绕过操作层，直接进入数据库，那么性能确实会更高。
秘籍全都交给你了，还不快去学习