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