其他分享
首页 > 其他分享> > 三层架构

三层架构

作者:互联网

三层架构

1.什么是三层?

UI(表现层):主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。

 

BLL:(业务逻辑层):UI层和DAL层之间的桥梁。实现业务逻辑。业务逻辑具体包含:验证、计算、业务规则等等。

 

DAL:(数据访问层):与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层,同时将业务层处理的数据保存到数据库。(当然这些操作都是基于UI层的。用户的需求反映给界面(UI),UI反映给BLL,BLL反映给DAL,DAL进行数据的操作,操作后再一一返回,直到将用户所需数据反馈给用户)

 

 

2.如何把三层联系起来呢?

这时候就出现了实体层(Entity)

三者联系关系   UL>BLL>DAL:

更比如说:

 服务员:只管接待客人;
厨师:只管做客人点的菜;
采购员:只管按客人点菜的要求采购食材;

他们各负其职,服务员不用了解厨师如何做菜,不用了解采购员如何采购食材;厨师不用知道服务员接待了哪位客人,不用知道采购员如何采购食材;同样,采购员不用知道服务员接待了哪位客人,不用知道厨师如何做菜。

他们三者是如何联系的?

比如:厨师会做:炒茄子、炒鸡蛋、炒面——此时构建三个方法( cookEggplant()、cookEgg()、cookNoodle())

顾客直接和服务员打交道,顾客和服务员(UI层)说:我要一个炒茄子,而服务员不负责炒茄子,她就把请求往上递交,传递给厨师(BLL层),厨师需要茄子,就把请求往上递交,传递给采购员(DAL层),采购员从仓库里取来茄子传回给厨师,厨师响应cookEggplant()方法,做好炒茄子后,又传回给服务员,服务员把茄子呈现给顾客。

 

这样就完成了一个完整的操作。

3,为什么使用三层?
使用三层架构的目的:解耦!!!

同样拿上面饭店的例子来讲:

(1)服务员(UI层)请假——另找服务员;厨师(BLL层)辞职——招聘另一个厨师;采购员(DAL)辞职——招聘另一个采购员;

(2)顾客反映:1>你们店服务态度不好——服务员的问题。开除服务员;
                          2>你们店菜里有虫子——厨师的问题。换厨师;

任何一层发生变化都不会影响到另外一层!!!

 

4,与两层的区别??
两层

 


(当任何一个地方发生变化时,都需要重新开发整个系统。“多层”放在一层,分工不明确耦合度高——难以适应需求变化,可维护性低、可扩展性低)

 

(发生在哪一层的变化,只需更改该层,不需要更改整个系统。层次清晰,分工明确,每层之间耦合度低——提高了效率,适应需求变化,可维护性高,可扩展性高)

 

综上:三层架构的

优势:1,结构清晰、耦合度低,2,可维护性高,可扩展性高;3,利于开发任务同步进行;容易适应需求变化

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

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

3、增加了代码量,增加了工作量
4,三层的具体表现形式??
 

 

 



UI(就是上面图片的最下面的):

 

 

(大家不要误会,UI层不只是一个个用户界面,也是需要有代码的)

(1,功能:用户输入数据、反馈给用户数据;2,大家观察代码:没有涉及到业务逻辑,直接传参、函数、方法调用,没有涉及到与数据库打交道的SQL语句和ADO.net)

 

BLL:


 

 

(1,BLL是表示层与数据访问层之间的桥梁,负责数据处理、传递;2,大家观察代码,没有涉及到界面上的控件,没有涉及到SQL语句和ADO.net)

DAL:

 

 

 

 

(1,以上是DAL层中调用数据库的类类、;2,大家观察代码,没有涉及到界面控件,没有涉及到业务逻辑;只有与数据库打交道的SQL语句和ADO.net)

 

Entity(Model)层:
引入来自数据库code first(自动生成类库)

观察以上三层:

1,实体类user作为参数贯穿于三层之间;

2,通过传参、方法调用来实现功能;

3,各层之间各负其责;互不影响

 

对比两层结构,让大家深刻体会三层的极大好处。


(观察上面的两层的代码:将业务逻辑、数据访问都展现在用户表现层,当需求需要改变时,需要改变整个系统。比如,我把文本框txtPassWord的名称改为txtPwd的话,大家观察一下得需要更改多少地方。这样的改动算是小的,如果真的有业务需求上的改动才叫麻烦复杂,程序员不跳楼才怪。呵呵、、开个玩笑)
与如此难以适应需求变化的两层相比,大家再次观察三层代码,再次思考,三层架构有什么好处呢?自己思考。。。。。

标签:架构,DAL,服务员,BLL,厨师,UI,三层
来源: https://www.cnblogs.com/wujie-8399/p/16390441.html