三层数据结构总结

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_39674002/article/details/82194682

前言

三层结构是传统的客户/服务器结构的发展,多层机构和三层结构的含义是一样的,只是细节有所不同.

软件架构

是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口(计算机科学)来实现。 软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

分层

分层是表示将功能进行有序的分组:应用程序专用功能位于上层,跨越应用程序领域的功能位于中层,而配置环境专用功能位于低层。分层从逻辑上将子系统划分成许多集合,而层间关系的形成要遵循一定的规则。通过分层,可以限制子系统间的依赖关系,使系统以更松散的方式耦合,从而更易于维护。子系统的分组标准包含以下几条规则可见度。各子系统只能与同一层及其下一层的子系统存在依赖关系。

分层设计的原则:

1、层意味着组建的逻辑分组。例如,对用户界面,业务逻辑和数据访问组建应该使用不同的不同的层。

2、在一个层内组建应该聚合的。如业务层组建仅应提供与业务逻辑相关的操作,而不是提供其他操作。

3、在设计的每一个层接口时要考虑好物理边界。如果通信扩月了物理边界,使用基于消息操作;否则使用基于对象操作。

4、考虑使用接口类型(interface)来定义每层的接口。这将允许你创建该接口的不同实现,提高可测性。

5、对于Web应用程序,在表示层和业务逻辑层之间实现基于消息的接口是一个好主意,即使这两层没有跨越物理边界。基于消息的接口更适合于无状态的Web操作。

 

三层结构图:

 

表现层(UI):

展现给用户的界面,即用户在使用一个系统的时候他的所见所得。依据应用规模的不同,所承受的负荷会有较大的差异,另外客户端的数目,应用的复杂程度都会对其造成一定的影响。

业务逻辑层(BLL):对数据层的操作和业务的处理。接收用户的指令或者数据输入,提交给应用层做处理,同时负责将业务逻辑层的处理结果显示给用户。相比传统的应用方式,业务层对硬件的资源要求较低。

数据层(DAL):直接操纵数据库,主要是增删改查的功能。存储数据的数据库服务器和处理数据和缓存数据的组件。组件将大量使用的数据放入系统的缓存库,以提高数据访问和处理的效率。

 

 

三者之间的依赖关系的体现:

数据访问层的类,直接访问数据库,实现基本记录操作。

业务逻辑层的类,调用相关的数据访问类,实现用户所需功能。

界面层:部署控件后,调用业务逻辑层的类,实现功能。

总结

三层结构主要体现出对程序分而治之的思想:数据访问层只负责提供原原始数据,并不需要了解业务逻辑;业务逻辑层调用数据访问层提供的方法自定义一些业务逻辑,对数据进行加工,本身不需要了解数据访问层的实现;表示层直接调用业务逻辑提供的方法把数据呈现给用户。

三层结构的优点在于不必为了业务逻辑上的微小变化而迁至整个程序的修改,只需要修改商业逻辑层中的一个函数或一个过程;增强了代码的可重用性;便于不同层次的开发人员之间的合作,只要遵循一定的接口标准就可以进行并行开发了,最终只要将各个部分拼接到一起构成最终的应用程序。

三层结构的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下,客户端不直接与数据库进行交互,而是通过COM/DCOM通讯与中间层建立连接,再经由中间层与数据库进行交互,这样会大大提高系统的安全性。

三层结构的应用程序更能够适应企业级应用日益增长的复杂度和灵活性的要求,并且通过软件分层的高内聚、低耦合的原则,实现扩展、维护和重用的要求,可以大大提高开发效率。

猜你喜欢

转载自blog.csdn.net/qq_39674002/article/details/82194682
今日推荐