现在的位置: 首页 > 综合 > 正文

《三层理论篇》一

2017年10月04日 ⁄ 综合 ⁄ 共 1022字 ⁄ 字号 评论关闭

一、联系生活:         

     先从我们的生活场景说起,我们要吃烧烤,一种情况是在路边,有人摆摊,我们要完东西之后就在这看着等着烤好了,然后拿着开始吃,第二种情况是我们到一个小店只要坐下来有人过来问你想吃什么,你说完之后过会就会有人把你要的东西送过来(这两种场景估计大家都有过哈)

          两种场景的烤肉过程:



我们生活中的这种烤肉现象就对应这我们系统的开发的两种方式,二层和三层(多层)。

         路边烤肉一个人什么都干,总有忙不过来出错的时候,当他积累到一定的钱之后可能就会去开店,这样就能满足更多的顾客。

    从路边烤肉到开店的过程和我们软件开发的过程一样,刚开始的时候我们也是在把所有的功能(数据输入,逻辑运算,数据库访问更新)都写在一个窗体里,然后在将软件分为,界面层,逻辑层,数据访问层。实现从二层到三层(多层)的转变。


二、二层图解:

特点:强耦合性


三、三层

定义:三层就是在逻辑上将软件分为三个层次结构,将各自的功能分开实现。

 

表现层UI只负责输入数据和显示数据:提供交互式系统界面。

业务逻辑层BLL表现层和数据访问层之间的桥梁,负责数据的逻辑运算,处理,传递。

数据访问层DAL直接针对的是数据库操作,对数据库进行相关的增删改查操作,更新数据。

图解:

层的理解:

   层是一种弱耦合结构,层与层之间的依赖是向下的,底层对于上层而言是“无知”的,改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时,遵循了面向接口设计的思想,那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下,理想的分层式架构,应该是一个支持可抽取、可替换的“抽屉”式架构。

 

核心:

         业务逻辑层是三层中的核心部分。

    通过对层的认识后我们可以得知业务逻辑层的设计对于一个支持可扩展的架构尤为关键,因为它扮演了两个不同的角色。对于数据访问层而言,它是调用者;对于表示层而言,它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上,如何实现依赖关系的解耦,则是除了实现业务逻辑之外另一个主要任务。

    中间层将复杂的商业逻辑(业务规则、数据访问、合法性校验等)从传统的双层结构应用模型中分离出来,并提供了可伸缩、易于访问、易于管理的方法,可以将多种应用服务分别封装部署于应用服务器,同时增强了应用程序可用性、安全性、封装复用性、可扩展性和可移置性,使用户在管理上所花费的时间最小化,从而实现了便捷、高效、安全、稳定的企业级系统应用。

 

抱歉!评论已关闭.