层次式架构设计理论与实践
- 13.1 层次式体系结构概述
- 13.2 表现层框架设计
- 13.2.1 表现层设计模式
- 13.2.2 使用XML设计表现层,统一Web Form与Windows Form的外观
- 13.2.3表现层中UIP设计思想
- 13.2.4 表现层动态生成设计思想
- 13.3 中间层架构设计
- 13.3.1 业务逻辑层组件设计
- 13.3.2 业务逻辑层工作流设计
- 13.3.3 业务逻辑层实体设计
- 13.3.4 业务逻辑层框架
- 13.4 数据访问层设计
- 13.4.1 5种数据访问模式
- 13.4.2 工厂模式在数据访问层应用
- 13.4.3 ORM、Hibernate与CMP2.0设计思想
- 13.4.4 灵活运用XML Schema
- 13.4.5 事务处理设计
- 13.4.6 连接对象管理设计
- 13.5 数据架构规划与设计
- 13.5.1 数据库设计与类的设计融合
- 13.5.2 数据库设计与XML设计融合
- 13.6 物联网层次架构设计
- 13.7 层次式架构案例分析
- 13.7.1 电子商务网站(网上商店PetShop)
- 13.7.2 基于物联网架构的电子小票服务系统
13.1 层次式体系结构概述
软件体系结构是指为软件系统提供高级抽象的结构、行为和属性的定义。它描述了系统的组织结构、元素之间的相互作用以及设计决策的原则,是系统级复用的基础。
软件体系结构在软件研发生命周期中起到重要的作用,主要体现在以下三个方面:
- 利益相关人员之间的交流:软件体系结构作为系统抽象,可以作为各利益相关人员进行沟通的基础。
- 系统设计的前期决策:软件体系结构是最早期的系统设计决策,对后续开发、部署和维护产生重要影响。
- 可传递的系统级抽象:软件体系结构是一种能够传递和应用于具有相似质量属性和功能需求的系统的模型,促进了系统级复用。
分层式体系结构是最常见的架构设计方法,通过将系统划分为多个层次,并定义层间的接口和协议,实现了设计简化、系统机构清晰、复用能力和产品维护能力的提高。
分层式体系结构通常包括表现层(展示层)、中间层(业务层)、数据访问层(持久层)和数据层。其中,组件在每个层次中负责各自层次的逻辑,实现了关注分离的原则。
虽然分层式体系结构是通用的架构模式,但需要注意避免出现污水池反模式,即每层缺乏业务逻辑的情况。此外,分层架构可能会导致应用变得庞大,带来复杂的分布模式、健壮性下降、可靠性和性能问题以及代码规模膨胀等潜在问题。
13.2 表现层框架设计
13.2.1 表现层设计模式
- MVC模式是一种广泛应用的软件设计模式,将应用的输入、处理和输出按照视图、控制器和模型的方式进行分离。
- 控制器负责接受用户输入并调用模型和视图来实现用户需求。
- 模型表示业务数据和逻辑,可以为多个视图提供数据。
- 视图显示相关数据并接收用户输入,但不进行实际的业务处理。
- 优点:允许多种用户界面的扩展,易于维护,功能强大的用户界面。
- MVP模式是从MVC演变而来,Model提供数据,View负责显示,Controller/Presenter负责逻辑处理。
- View通过Presenter与Model交互,避免了View和Model之间的耦合。
- Presenter依赖抽象化的View接口,易于对Presenter进行测试。
- 可将一个Presenter用于多个视图,提高代码重用性。
- 优点:模型与视图完全分离,高效利用模型,便于测试逻辑。
- MVVM模式是为解决MVP中视图种类和接口增加的问题而提出的,通过ViewModel实现View和Model的分离。
- ViewModel通过DataBinding实现View与Model的双向绑定。
- ViewModel是一个专门用于数据转换的控制器,处理数据状态、绑定和转换。
- View和ViewModel使用DataBinding和事件进行通信,实现视图与视图模型的同步更新。
- 优点:适用于数据驱动场景,数据和视图双向绑定,提高响应性。
注意:MVVM模式最好使用官方的架构组件ViewModel、LiveData等实现。
13.2.2 使用XML设计表现层,统一Web Form与Windows Form的外观
XML(可扩展标记语言)是一种类似于HTML的标记语言,用于定义数据的结构和数据类型。尽管XML被公认为优秀的数据描述语言并成为广泛采用的标准,但在表现层技术中,HTML仍然是主要角色。由于Web应用程序对特定浏览器的局限和性能问题,基于窗体的胖客户端应用程序正在重新流行。许多开发厂商提出了同时支持胖客户端和Web表现形式的产品开发。因此,有人提出使用一个标准的GUI描述形式,并根据其描述转换成不同的表现形式。这就要求描述语言具有很好的通用性和扩展性,而XML恰好是理想的载体。对于大多数应用系统,GUI主要由GUI控件组成,而XML可以很好地支持控件之间的层次结构。同时,XML标记由架构或文档的作者定义,并且是无限制的,因此架构开发人员可以约定控件的属性,例如按钮、控件容器、位置等。通过使用XML来描述整个GUI,可以简化GUI的开发和维护。从设计模式的角度来看,XML表现层解析机制采用了策略模式,通过装载GUI对应的XML配置文件并根据特定的表现技术解析XML,得到GUI视图实例对象。这样,GUI开发人员只需要维护一套XML文件即可。
13.2.3表现层中UIP设计思想
应用程序通常需要使用代码来管理用户界面,例如窗体之间的导航。然而,将这些代码写在用户界面的代码中会导致代码复杂、难以复用、维护和扩展。同时,如果应用程序需要在不同平台上运行,控制逻辑和状态无法复用。
大多数应用程序需要维护一个状态,通常存储在窗体中,代码需要访问窗体来恢复状态。这样做会变得困难且不优雅,同时也会影响用户界面的可重用性和可扩展性。
当用户使用应用系统时,可能会启动一个任务,一段时间后返回继续。如果在此期间用户关闭了应用程序,他们将失去当前的状态,必须从头开始任务。因此,在设计程序时,需要分别考虑工作流、导航和与商业服务的交互等不同组成部分,以获取和呈现数据给用户。
UIP(UserInterface Process Application Block)是微软社区开发的众多Application Block之一,也是开源的。UIP提供了一个扩展的框架,用于简化用户界面与商业逻辑代码的分离方法,可以用它来编写复杂的用户界面导航和工作流处理,并且可以在不同场景中重用,并随着应用的增长进行扩展。
使用UIP框架的应用程序将表现层分为以下几层:
- 用户界面组件(User Interface Components):这是用户看到和交互的部分,负责获取用户数据并返回结果。
- 用户界面处理组件(User Interface Process Components):这个组件用于协调用户界面的各个部分,配合后台活动,例如导航和工作流控制,以及状态和视图的管理。用户看不到这一组件,但它为用户界面组件提供重要的支持功能。
UIP组件的主要功能是管理通过用户界面组件的信息流,管理UIP中各个事件之间的事务,修改用户过程的流程以响应异常,将概念上的用户交互流程与实现或涉及的设备分离,保持内部的事务关联状态,通常持有一个或多个与用户交互的事务实体。因此,这些组件还可以从用户界面组件收集数据,执行服务器的批量更新或跟踪UIP中的任务进程的管理。
13.2.4 表现层动态生成设计思想
基于XML的界面管理技术可以实现灵活的界面配置、界面动态生成和界面定制。其思路是使用XML生成配置文件和界面所需的元数据,根据不同需求生成界面元素和软件界面。
基于XML界面管理技术包括界面配置、界面动态生成和界面定制三个部分。界面配置是对用户界面的静态定义,通过读取配置文件的初始值来配置界面。界面定制是在软件运行过程中对界面元素进行动态修改,用户可以根据需求和使用习惯修改界面元素的属性。系统通过DOM API读取XML配置文件的表示层信息,通过数据存取类读取数据库中的数据层信息,运行时动态生成界面。界面配置和定制模块可以在软件运行前后修改配置文件和更改界面内容。
基于XML的界面管理技术实现了用户界面描述信息与功能实现代码的分离,可以根据不同的用户需求进行界面配置和定制,并且能够适应一定程度上的数据库结构改变。只需要稍微修改XML文件,就可以实现系统的移植。
13.3 中间层架构设计
13.3.1 业务逻辑层组件设计
业务逻辑组件分为接口和实现类两部分。接口定义了业务逻辑组件必须实现的方法,是系统运行的核心。每个模块都设计一个业务逻辑组件,通过多个DAO组件实现对外提供业务逻辑服务。为了解耦,控制器使用业务逻辑组件的接口进行编程。
业务逻辑组件的实现类以DAO组件为基础,并接收Spring容器注入的DAO组件。复杂的业务逻辑可能需要访问多个对象的数据,可以在实现类的方法中调用多个DAO接口,将具体实现委派给DAO完成。
业务逻辑组件的配置需要使用Spring的反向控制(IoC)或依赖注入(DI)机制,即在applicationContext.xml中配置FacadeManager组件,并为其配置所需的DAO组件。
在配置文件中,采用继承业务逻辑组件的事务代理,将原有的业务逻辑组件作为嵌套bean配置,避免直接调用没有事务特性的业务逻辑组件。
系统实现了后台业务逻辑,并提供统一的Facade接口,前台Web层仅依赖该接口。这样,Web层与后台业务层的耦合度低,方便在不同的Web框架中切换。
13.3.2 业务逻辑层工作流设计
工作流是指业务流程的部分或全部自动化,在此过程中,文档、信息或任务按照一定的过程规则流转,实现组织成员间的协调工作以达到业务的整体目标。工作流管理联盟制定了工作流参考模型和五个接口,包括过程定义导入/导出接口、客户端应用程序接口、应用程序调用接口、工作流机协作接口和管理和监视接口。用工作流的思想组织业务逻辑可将应用逻辑与过程逻辑分离,在不修改具体功能的情况下,通过修改过程模型改变系统功能,完成对生产经营部分过程或全过程的集成管理,实现最大效能。
13.3.3 业务逻辑层实体设计
业务逻辑层实体具有以下特点:
- 提供对业务数据及相关功能的状态编程访问。
- 使用复杂架构的数据构建,通常来自数据库中的多个相关表。
- 可作为业务过程的部分输入输出参数传递。
- 可序列化,可以保存当前状态,存储在本地磁盘、数据库或消息队列中。
- 不直接访问数据库,所有数据库访问由数据访问逻辑组件提供。
- 不启动事务处理,由应用程序或业务过程来启动。
- 可以使用不同的表示方法,如XML、通用DataSet、有类型的DataSet等。
将业务逻辑层实体表示为XML的优点:
- 标准支持,XML是W3C的标准数据表示格式。
- 灵活性,能够表示信息的层次结构和集合。
- 互操作性,适用于各平台间交换信息。
- 可以使用DataSet进行数据绑定。
将业务逻辑层实体表示为通用DataSet的优点:
- 灵活性,能够表示复杂的数据关系。
- 支持序列化,便于在层间传递。
- 支持数据绑定,可与用户界面控件进行绑定。
- 支持排序和过滤,可以创建多个DataView对象查看数据。
- 支持与XML的互换。
- 支持开放式并发检查。
- 可扩展性,适应数据库架构的修改。
将业务逻辑层实体表示为有类型的DataSet的优点:
- 代码易读,使用有类型的方法和属性访问表和列。
- 使用有类型的方法和属性更方便,具有IntelliSense支持。
- 编译时类型检查,可以在编译时检测无效的表名称和列名称。
13.3.4 业务逻辑层框架
业务框架是系统功能的核心组件,位于系统架构中间层。采用容器形式实现,便于开发、代码重用和管理。在业务容器中,采用Domain Model—Service—Control思想来实现业务逻辑。Domain Model是业务相关属性的领域层业务对象,Service是应用程序不同功能单元,通过定义中立接口联系起来,Control作为服务控制器,决定Service之间的执行顺序及相互关系。通过隔离服务和服务控制,实现高度的可重用性和灵活性。
13.4 数据访问层设计
13.4.1 5种数据访问模式
- 在线访问是最常用的数据访问模式,通过数据库连接读取数据并与后台数据源进行交互。
- DAO模式将底层数据访问操作与高层业务逻辑分离,常用于Web应用开发。
- DTO模式是一种数据传输对象模式,用于在不同进程或网络边界传输数据,通常不包含具体业务逻辑。
- 离线数据模式以数据为中心,在系统中存储按预定义结构存放的数据,独立于数据源连接或事务。
- 对象/关系映射(O/R Mapping)是一种将应用程序中的对象数据转换成关系型数据库记录或相反的工具或平台。
13.4.2 工厂模式在数据访问层应用
在应用程序设计中,数据库的访问需要良好的封装性和可维护性。为了做到数据库无关,可以采用工厂设计模式。在实际开发中,先定义一个操作数据库的接口,然后根据数据库不同,由类工厂决定实例化哪个类。通过创建一个Factory类,根据数据库类型返回适当的数据库操纵类,实现自动数据库切换的管理。客户端调用时,只需要修改PersistenceProperty的值,程序不会受到影响,实现了良好的封装性。
13.4.3 ORM、Hibernate与CMP2.0设计思想
ORM(对象关系映射)是一种将关系型数据库和对象之间进行映射的技术。通过使用ORM,开发者可以像操作对象一样操作数据库,而不需要编写复杂的SQL语句。ORM可以减少代码的重复性,降低学习和开发成本,并且提高开发效率。
Hibernate是一个开源的ORM框架,它提供了轻量级的对象封装,使Java程序员可以使用面向对象的方式来操作数据库。Hibernate不仅提供了对象到数据表的映射,还提供了数据查询和恢复机制。相比于手动操作数据库,Hibernate可以大大减少工作量,并且可以利用代理模式简化数据提取的代码编写量。Hibernate可以与多种Web服务器和应用服务器集成,并支持各种流行的数据库服务器。
Hibernate是一个功能强大的ORM框架,可以有效地将数据库数据映射到业务对象中。它使开发人员能够专注于业务逻辑而不必关注繁琐的数据库操作。通过自动生成持久层,Hibernate提供了更合理的模块划分和开发方式。
13.4.4 灵活运用XML Schema
XML Schema是用于描述XML文档结构和限制的语言,它使用命名空间、具有丰富的内嵌数据类型和数据结构定义功能。与传统的DTD机制相比,它更加强大并逐渐代替DTD成为XML体系中正式的类型语言。XML Schema由基本组件、组件和帮助组件组成,详细说明了每个组件的语义和在XML中的表示。XML Schema规范由Primer、Structures和Datatypes三部分组成,其中Datatypes定义了可用于XML Schema和其他XML规范中的数据类型。与DTD不同,XML Schema提供了丰富的数据类型和继承性,使得软件开发和维护更加高效。同时,XML Schema与XML Namespace紧密联系,简化了多个命名空间定义多个Schema的XML文档的创建和验证。
13.4.5 事务处理设计
事务是现代数据库理论中的核心概念之一,表示一组处理步骤。事务必须遵循ACID原则,即原子性、一致性、隔离性和持久性。J2EE应用服务器支持JDBC事务、JTA事务和容器管理事务。在JDBC事务中,可以将多个SQL语句组合成一个事务,并使用commit()方法提交事务。在JTA事务中,可以通过UserTransaction接口开始、提交或回滚事务。处理事务时应尽量短且避免嵌套使用不同类型的事务。
13.4.6 连接对象管理设计
在基于JDBC的数据库应用开发中,数据库连接的管理是决定性能的重要因素。为了解决连接频繁分配和释放的问题,可以使用连接池来提供高效的连接分配和使用策略。连接池在系统初始化时就建立,并存放预分配好的连接。客户请求连接时,先检查连接池是否有空闲连接,如果有则分配给客户,并标记为已分配。如果没有空闲连接,则在已分配连接中寻找可复用的连接。当客户释放连接时,根据是否被复用进行不同处理,未被使用者复用的连接放回连接池而不关闭,实现了连接的有效复用。
13.5 数据架构规划与设计
13.5.1 数据库设计与类的设计融合
正确识别类和类之间的关系是数据模型的关键。建模是一项艺术,不存在唯一正确的数据模型,但可以存在好的数据模型。好的数据模型应该考虑项目整个生命周期的成本,并能适应系统可能发生的变化。因此,将重点放在降低开发费用上是错误的。
13.5.2 数据库设计与XML设计融合
Web的迅速发展使得 Web数据变得更加复杂和多样化,传统数据库技术难以存储和管理所有不同的 Web 数据。XML正在成为Internet上数据描述和交换的标准,并且将来会代替 HTML而成为 Web 上保存数据的主要格式。 XML文档分为两类,一类是数据文档,用于存储和传输 Web 数据;另一类是以文档为中心的文档,常用于在网页上发布描述性信息、产品性能介绍和 E-mail信息等。目前提出了两种 XML文档的存储方式:基于文件的存储方式和数据库存储方式。 XML数据库是一组XML文档的集合,并且是持久的和可操作的;有专门的DBMS管理;文档都是有效的,文档的集合可能基于多个模式文件。
13.6 物联网层次架构设计
物联网分为三个层次:感知层、网络层和应用层。感知层用于识别物体和采集信息,包括各种传感器和识读设备;网络层用于传输和处理数据,将感知层获取的信息进行传递和预处理;应用层结合行业需求实现广泛智能化,提供丰富的特定服务。物联网是深度信息化的重要体现,软件开发和智能控制技术将会为用户提供丰富多彩的物联网应用。
13.7 层次式架构案例分析
13.7.1 电子商务网站(网上商店PetShop)
PetShop是一个基于.Net企业系统开发能力的范例,展示了设计和开发理念。它采用B/S系统架构,其中表示层使用ASP.Net设计。随着版本的更新,其分层结构逐渐完善,最新版本是基于.Net 2.0的PetShop 4.0。
在早期版本中,没有明显的数据访问层设计,导致业务逻辑层和数据访问的职责混乱。但随着PetShop 3.0的发布,将数据访问逻辑独立出来作为单独的一层,解决了这个问题。
PetShop 4.0延续了3.0的架构,引入了缓存和异步处理机制,并利用了ASP.Net 2.0的新功能MemberShip。
整个系统架构中,数据访问层采用面向接口编程的思想,抽象出IDAL模块,使得数据访问层有利于数据库迁移。业务逻辑层通过接口模块IDAL调用数据访问层,实现了松散耦合的层与层之间的关系。
PetShop的表示层和业务逻辑层之间的调用关系相对较高耦合。同时,表示层还引入了辅助模块,如Messaging模块用于异步插入订单的功能,CacheDependency提供缓存功能。
总的来说,PetShop的设计和开发理念在系统架构、分层结构和面向接口编程等方面有很多值得借鉴的地方。
13.7.2 基于物联网架构的电子小票服务系统
-
电子小票物联网架构是基于感知层、网络层和应用层的三层模型。感知层包括取代传统小票打印机的智能硬件,通过Wi-Fi/GPRS传输购物小票信息到云平台。网络层支持数据传输、处理和存储,并提供服务支持。应用层是电子小票服务系统与顾客和商家的接口,包括实时推送、历史查询和数据管理等功能。
-
电子小票服务系统由小票智能硬件、商家收银机、电子小票云平台、微信公众平台、消费者智能手机和商家PC终端构成。小票智能硬件通过控制器、TFTLCD显示屏、Flash存储和无线模块实现数据显示和上传。商家收银机不需改变原有系统,只需安装驱动程序即可使用智能硬件作为打印机。云平台通过微信公众平台将电子小票实时推送给消费者微信应用。