13.1层次式体系结构概述

软件体系结构：软件体系结构为软件系统提供了结构、行为和属性的高级抽象，由构成系统的元素描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。

软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理，是构建于软件系统之上的系统级复用。

层次式体系结构设计是将系统组成一个层次结构，每一层为上层服务，并作为下层客户。
在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。
在分层次体系结构中的组件被划分成几个层，每个层代表应用的一个功能，都有自己特定的角色和职能。分层架构本身没有规定要分成多少层，大部分的应用会分成表现层(或称为展示层)、中间层(或称为业务层)、数据访问层(或称为持久层)和数据层。

分层架构的一个特性就是关注分离 (separation of concerns)。 该层中的组件只负责本层的逻辑，组件的划分很容易明确组件的角色和职责，也比较容易开发、测试、管理和维护。

需要注意
(1)污水池反模式：分层架构中某层不处理业务，仅转发请求，造成无效分层。
若这类请求占比过高（>20%），说明架构设计不合理。
(2)需要考虑的是分层架构可能会让你的应用变得庞大。

13.2表现层框架设计

13.2.1表现层设计模式

1.MVC模式

MVC强制性地把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离，形成了控制器、模型、视图三个核心模块。

组成	核心作用	关键特点
视图(View)	用户交互界面，显示数据、接收输入	不处理业务逻辑，仅查询模型状态，同步更新界面
控制器(Controller)	接收用户输入，调用模型与视图完成需求；是视图与模型的接口	解释用户输入并调用模型方法，处理模型结果并调用视图反馈
模型(Model)	应用主体，承载业务数据与业务逻辑	可被多个视图复用，提高应用可重用性

2.MVP模式

MVP(Model-View-Presenter)： Controller/Presenter 负责逻辑的处理， Model提供数据， View负责显示

区别
MVC：允许View和 Model 直接进行“交流”
MVP：View并不直接使用 Model, 它们之间的通信是通过 Presenter(MVC 中的 Controller) 来进行的

优点
(1)模型与视图完全分离，可以修改视图而不影响模型。
(2)可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter 内部。
(3)可以将一个 Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
(4)如果把逻辑放在Presenter中，就可以脱离用户接口来测试这些逻辑(单元测试)。

3.MVVM模式

MVVM模式正是为解决MVP 中U I种类变多，接口也会不断增加的问题而提出的。

M V V M模式全称是模型-视图-视图模型 (Model-View-ViewModel), 它和 M V C 、 M V P类似，主要目的都是为了实现视图和模型的分离，不同的是M V V M中，View与 Model的交互通过ViewModel来实现。

通 过DataBinding实 现View与Model之间的双向绑定，其内容包括数据状态处理、数据绑定及数据转换。

13.2.2使用XML设计表现层，统一WebForm与WindowsForm的外观

X M L (可扩展标记语言)与 H T M L 类似，是一种标记语言。与主要用于控制数据的显示和外观的 H T M L 标记不同， XML标记用于定义数据本身的结构和数据类型。

13.2.3表现层中UIP设计思想

传统界面将流程、导航、状态写在 UI 中，导致复用性差、难以维护；

UIP 框架将表现层拆分为界面组件（UIC）与界面流程组件（UIP），分离界面与流程逻辑，统一管理导航、工作流与用户状态，提高复用性、可维护性与扩展性。

13.2.4表现层动态生成设计思想

基于 X M L 的界面管理技术可实现灵活的界面配置、界面动态生成和界面定制。其思路是
用 X M L 生成配置文件及界面所需的元数据，按不同需求生成界面元素及软件界面。

基于 X M L界面管理技术，包括界面配置、界面动态生成和界面定制三部分

13.3中间层框架设计

13.3.1业务逻辑层组件设计

业务逻辑组件分为接口和实现类两个部分。

13.3.2业务逻辑层工作流设计

工作流定义为：业务流程的全部或部分自动化，在此过程中，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作以达到业务的整体目标。

接口	名称	核心功能
Interface 1	过程定义导入/导出接口	支持过程定义格式转换与API调用；早期标准WPDL，后为XPDL
Interface 2	客户端应用程序接口	工作流机与任务表处理器交互，组织、选择、推进任务，控制应用工具活动
Interface 3	应用程序调用接口	工作流机直接激活后台应用工具执行活动；需用户交互时走Interface 2
Interface 4	工作流机协作接口	定义标准，实现不同厂商工作流系统间无缝传递任务项
Interface 5	管理和监视接口	提供用户/角色管理、审查、资源控制、过程管理与状态监控

13.3.4业务逻辑层实体设计

业务逻辑层实体具有以下特点：
1、业务逻辑层实体提供对业务数据及相关功能(在某些设计中)的状态编程访问。
2、业务逻辑层实体可以使用具有复杂架构的数据来构建，这种数据通常来自数据库中的多个相关表。
3、业务逻辑层实体数据可以作为业务过程的部分 I/O 参数传递。
4、业务逻辑层实体可以是可序列化的，以保持它们的当前状态。

13.3.4业务逻辑层框架

业务框架位于系统架构的中间层，是实现系统功能的核心组件。采用容器的形式，便于系统功能的开发、代码重用和管理。

在业务容器中，业务逻辑是按照 Domain Model—Service—Control 思想来实现的

组件	职责	核心特点
Domain Model（领域模型）	领域层业务对象，仅包含业务相关属性	承载业务状态，被 Service 依赖并被其修改
Service（业务服务）	实现业务过程，通过中立接口松耦合交互	松耦合、灵活，内部实现变化不影响整体结构
Control（服务控制器）	服务间的纽带，控制服务执行顺序与切换	实现与调度分离，提升重用性与灵活性

1. Service 依赖 Domain Model 的状态，并根据业务规则更新其状态。
2. Control 根据 Domain Model 状态与参数，决定各 Service 的执行顺序与调用关系。

由 MVC 演变而来，在控制与展示分离基础上，进一步实现服务实现与服务控制分离，使系统具备高可重用性与灵活性。

13.4数据访问层设计

13.4.1五种数据访问模式

模式	核心说明	组成/特点
在线访问	最基本、最常用；占用数据库连接，每次操作直接与数据源交互	持续占用连接，实时交互
DAO（DataAccess Object）	J2EE标准模式，分离底层数据访问与高层业务逻辑	包含：DAO工厂类、DAO接口、实现类、DTO
DTO（Data Transfer Object）	跨进程/网络传输的数据容器，不含业务逻辑	两种实现：内置集合（简便、弱类型）、自定义类（强类型、编译检查）
离线数据模式	以数据为中心，操作独立于数据源连接与事务	支持XML转换，结构独立于具体数据源（如SDO、DataSet）
O/R Mapping	对象与关系型数据自动转换	解决对象模型与关系数据库不匹配问题，实现数据持久化

13.4.2工厂模式在数据访问层应用

13.4.3ORM、Hibernate与CMP2.0设计思想

13.4.4灵活运用XML Schema

13.4.5事务处理设计

事务是现代数据库理论中的核心概念之一。
如果一组处理步骤或者全部发生或者一步也不执行，我们称该组处理步骤为一个事务。
当所有的步骤像一个操作一样被完整地执行，我们称该事务被提交。
由于其中的一部分或多步执行失败，导致没有步骤被提交，则事务必须回滚(回到最初的系统状态)。

事务必须服从 ISO/IEC所制定的ACID 原则

特性	英文	核心含义
原子性	Atomicity	事务中所有操作要么全部成功，要么全部失败回滚，任何失败都导致修改失效
一致性	Consistency	事务执行前后，数据始终保持合法一致的状态
隔离性	Isolation	事务在提交前，对数据的修改对其他事务不可见
持久性	Durability	事务一旦提交，对数据的修改永久保存，即使后续系统故障也不会丢失

13.4.6连接对象管理设计

对于共享资源，有一个很著名的设计模式——资源池。该模式正是为了解决资源频繁分配、释放所造成的问题。把该模式应用到数据库连接管理领域，就是建立一个数据库连接池，提供一套高效的连接分配、使用策略。

13.5数据架构规划与设计

13.5.1数据库设计与类的设计融合

13.5.2数据库设计与XML设计融合

XML 相关知识点整理表

XML 文档分类

类型	结构与内容特点	应用场景
以数据为中心（数据文档）	结构规则、内容同构；混合内容与嵌套层次少；不关心元素顺序	Web 数据存储与传输
以文档为中心	结构不规则、内容零散；混合内容多；元素顺序有意义	网页描述信息、产品介绍、E-mail 等

XML 文档存储方式对比

存储方式	实现方式	特点
基于文件的存储	按原始文本存储；存为 BLOB/CLOB，需附加索引	无法获取结构化数据；依赖关键字定位；仅返回完整文档；容量大、管理难
数据库存储	利用数据库管理 XML 数据	支持结构化/半结构化数据；可操作文档内部数据；具备多用户、并发、一致性约束；管理方便高效

XML 与传统数据库对比

对比项	XML 相关技术	传统数据库
具备能力	存储、模式（DTD/Schema）、查询语言（XQuery/XPath）、编程接口（SAX/DOM）	完善的存储、索引、安全、多用户、事务管理
不足	存储、索引、安全、多用户、事务管理较弱	—
适用场景	数据量小、用户少、性能要求不高	多用户、高完整性、高性能要求场景

XML 数据库定义

• 是持久可操作的 XML 文档集合
• 由专用 DBMS 管理（非 XML 文件系统）
• 文档符合对应模式（DTD/XSD）
• 可基于多个关联模式文件

13.6物联网层次架构设计

物联网三层架构整理表

层次	核心作用	主要组成	关键技术	典型应用
感知层	识别物体、采集信息；解决物理世界数据获取问题	二维码/RFID、传感器、摄像头、GPS、传感器网关等	检测技术、短距离无线通信（RFID、蓝牙、红外等）	ETC、仓储管理、行李自动分类
网络层	信息传递与处理；类似人体神经中枢和大脑	通信网/互联网融合、网络管理中心、智能处理中心、云计算平台	长距离有线/无线通信、网络技术、数据管理与挖掘	手机付费、后台鉴权、银行划账
应用层	实现行业智能化；信息处理与人机交互	行业应用系统、终端人机接口；分应用程序层+终端设备层	软件开发、智能控制技术	物流监控、智能家居、智能交通、远程抄表

13.7层次式架构案例分析

13.7.1电子商务网站(网上商店PetShop)

PetShop 的表示层是用ASPNet设计的，也就是说，它应是一个B/S系统
随着 PetShop版本的更新，其分层式结构也在不断完善，例如 PetShop 2.0, 就没有采用标准的三层式结构

PetShop3.0纠正了此前层次不明的问题，将数据访问逻辑作为单独的一层独立出来。

PetShop 4.0基本上延续了3.0的结构，但在性能上作了一定的改进，引入了缓存和异步处理机制 ， 同 时又充分利用了ASP.Net 2.0的新功能MemberShip。

13.7.2基于物联网架构的电子小票服务系统

1.电子小票物联网架构

采用感知层、网络层和应用层的3层物联网体系架构模型

2.电子小票服务系统架构