案例分析专题——层次式架构

层次式架构是软件体系结构设计中最为常用的一种架构形式，它为软件系统提供了一种在结构、行和属性方面的高级抽象，其核心思想是将系统组成为一种层次结构，每一层为上层服务，并作为下层客户。本文重点介绍了层次式架构中的表现层、中间层、访问层和数据层的体系结构设计技术，并给出了层次式架构的案例分析。

相关阅读：调用/返回风格

1 基本概念

软件体系结构为软件系统提供了结构、行和属性的高级抽象，由构成系统的元素描述这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。层次式体系结构（Hierarchical Architecture）设计是一种常见的架构设计方法，它将系统组成为一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。层次式体系结构的每一层最多只影响两层，同时只要给相邻层提供相同的接口，也允许每层用不同的方法实现，这种方式也为软件重用提供了强大的支持。

大部分应用分成表现层（或展示层）、中间层（或业务层）、访问层（或持久层）、数据层，如下图所示：

采用分层架构设计的一个特点就是关注点分离。每层中的组件只负责本层的逻辑，组件的划分也很容易明确组件的角色和职责，比较容易开发、测试、管理和维护。层次式体系结构是一个可靠的通用的架构，但设计时要注意以下两点：

1. 容易成为污水池反模式（Architecture Sinkhole Anti-patter）：请求流简单地穿过几个层，每层里面基本没有做任何业务逻辑，或者做了很少的业务逻辑。例如一些Java EE案例中，业务逻辑层只是简单地调用了持久层的接口，本身没有什么业务逻辑。
2. 分层架构可能会让应用变得庞大。

---

2 表现层框架设计

表现层又称为展示层。尽管常出现“MVC架构”“MVC架构风格”的说法，实际上MVC/MVP/MVVM要实现完整流程还需ORM，故严格讲仅属于模式。

2.1 MVC

MVC（Model-View-Controller）是一种软件设计模式，把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离，形成了控制器、模型、视图3个核心模块。其中：

1. Model（模型）：应用程序的主体部分，表示业务数据和业务逻辑。一个模型通常为多个视图提供数据，提高应用的可重用性。
   • 在J2EE体系结构中为EJB（Entity Bean、Session Bean等）
2. View（视图）：用户看到并与之交互的界面。接收用户输入数据，向用户展示数据。
   • 在J2EE体系结构中为JSP
3. Controller（控制器）：用户界面与Model的接口。接受用户的输入，并调用模型和视图去完成用户的需求。
   • 在J2EE体系结构中为Servlet

使用MVC模式来设计表现层，具有以下优点：

1. 允许多种用户界面的扩展
2. 易于维护
3. 易于构件功能强大的用户界面
4. 增加应用的可拓展性、强壮性、灵活性

2.2 MVP

MVP（Model-View-Presenter）是MVC的变种。在MVP模式中Model提供数据，View负责显示，Controller（又称Presenter）负责逻辑的处理。MVP不仅避免了View和Model之间的耦合，还进一步降低了Presenter对View的依赖。

优点如下：

1. 模型与视图完全分离，可以修改视图而不影响模型（做了严格分层；MVC并非严格分层）。
2. 可以更高效地使用模型，因为所有交互都发生在Presenter内部。
3. 可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。因为视图的变化总是比模型的变化频繁。
4. 若把逻辑放在Presenter中，则可脱离用户接口来测试这些逻辑（单元测试）。

2.3 MVVM

MVVM（Model-View-ViewModel）和MVC、MVP类似，主要目的都是为了实现视图和模型的分离。不同的是MVVM中，View和Model的交互通过ViewModel来实现，即View和Model不能直接通信，两者的通信只能通过ViewModel来实现。ViewModel是MVVM的核心，通过DataBinding实现View与Model之间的双向绑定，其内容包括数据状态处理、数据绑定及数据转换。

---

3 中间层框架设计

中间层又称业务层。

3.1 组件设计

业务逻辑层组件分为接口和实现类两个部分。接口用于定义业务逻辑组件，定义业务逻辑组件必须实现的方法是整个系统运行的核心。通常按模块来设计业务逻辑组件，每个模块设计一个业务逻辑组件，并且每个业务逻辑组件以多个数据访问对象（Data Access Object，DAO）组件作为基线，从而实现对外提供系统的业务逻辑服务。

3.2 工作流设计

工作流管理联盟（Workflow Management Coalition，WFMC）将工作流定义为：业务流程的全部或部分自动化，在此过程中，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作已达到业务的整体目标。

下图为工作流参考模型：

3.3 实体设计

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

3.4 业务逻辑层框架

业务逻辑框架位于系统架构的中间层，是实现系统功能的核心组件。采用容器的形式，便于系统功能的开发、代码重用和管理。在业务容器中，业务逻辑按照Domain Model-Service-Control思想来实现，其中：

1. Domain Model：仅包含业务相关的属性的领域层业务对象。
2. Service：是业务过程实现的组成部分，是应用程序的不同功能单元，通过在这些服务之间定义良好的接口和契约联系起来。
3. Control：服务控制器，是服务之间的纽带，不同服务之间的切换就是通过它来实现的。

---

4 数据访问层框架设计

访问层又称持久层。

4.1 数据访问模式

数据访问模式有5种：

1. 数据库在线访问：最常用的方式。访问占用一个数据库连接，读取数据，每个数据库操作都会通过这个连接不断地与后台的数据源进行交互。
2. Data Access Object（DAO）：标准J2EE设计模式，这种方式将底层数据访问操作与高层业务逻辑分离。一个典型的DAO实现通常会有一个DAO工厂类、一个DAO接口、一个实现了DAO接口的具体类、数据传输对象。
3. Data Transfer Object（DTO）：EJB设计模式之一。DTO是一组对象或容器，需要跨越不同的进程或是网络的边界来传输数据。
4. 离线数据模式：以数据为中心，数据从数据源获取之后，按照某种预定义的结构存放在系统中，成为应用的中心。这种方式对数据的各种操作，独立于各种与后台数据源之间的连接或事务。
5. 对象-关系映射：利用工具或平台将应用程序中的数据转换成关系型数据库中的记录，或将关系数据库中的记录转换成应用程序中代码便于操作的对象。

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

新考纲已不再要求设计模式案例分析题，此处仅供拓展

工厂设计模式是数据访问层中的主要使用方法。要实现工厂模式在数据数据访问层的应用，需要在实际开发过程中将这些数据库访问类再作一次封装。不仅可以达到上述目标，还可以减少操作数据库的步骤，减少代码编写量。

工厂模式定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。可能会涉及对多种数据库的操作，因此需要先定义一个操纵数据库的接口，然后根据数据库的不同，由类工厂决定实例化哪个类。

4.3 ORM

ORM（Object Relational Mapping）在关系型数据库和对象之间建立映射，使得在具体操纵数据库时，无需再去和复杂的SQL语句打交道，只需像平时操作对象一样操作即可。

映射关系表：

面向对象	关系数据库
类（Class）	数据库的表（Table）
对象（Object）	记录（Record，行数据）
对象的属性（Attribute）	字段（Field）

Hibernate是一个功能强大，可以有效地进行数据库数据到业务对象的O/R映射方案。Hibernate推动了基于普通Java对象模型，用于映射底层数据结构的持久对象的开发。

Hibernate与MyBatis（旧称iBatis）实现技术对比表：

维度	Hibernate	MyBatis
简单对比	强大，复杂，间接，SQL无关	小巧，简单，直接，SQL相关
可移植性	好（不关心具体数据库）	差（根据数据库SQL编写）
复杂多表关联	不支持	支持

4.4 XML Schema

新考纲已不再要求XML详细技术案例分析题，此处仅供拓展

XML Schema用于描述XML文档合法结构、内容和限制，提供丰富的数据类型。

XML Schema由XML 1.0自描述，并且使用了命名空间，有丰富的内嵌数据类型及其强大的数据结构定义功能，充分地改造了并且极大地扩展了DTD（Document Type Definition，定义传统描述XML文档结构和内容限制）的能力，将逐步替代DTD成为XML体系中正式的类型语言，同XML规范、Namespace规范一起成为XML体系的坚实基础。

4.5 事务处理设计

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

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

1. 原子性（Atomicity）：事务执行过程中的任何失败都将导致事务所做的任何修改失效。
2. 一致性（Consistency）：当事务执行失败时，所有被该事务影响的数据都应该恢复到事务执行前的状态。
3. 隔离性（Isolation）：在事务执行过程中对数据的修改，在事务提交之前对其他事务不可见。
4. 持久性（Durability）：已提交的数据在事务执行失败时，数据的状态都应该正确。

4.6 连接对象管理设计

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

建立连接池的第一步为建立静态连接池，其中静态是指池中的连接在系统初始化时即已分配好，并且不能够随意关闭。该静态连接池提供了一套可自定义的分配、释放策略。当客户请求数据库连接时，首先看连接池中是否有未分配出去的连接，若存在空闲连接则把连接分配给客户，并作相应处理。

---

5 数据架构规划与设计

5.1 数据库与类的设计融合

对类和类之间关系的正确识别是数据模型的关键所在。

要想将建模过程缩减为一个简单的、逐步进行的过程是不太可能的。从本质上讲，建模是一项艺术。对一个给定的复杂情况而言，不存在唯一正确的数据模型，然而却存在好的数据模型。一个企业或机构的某个数据模型可能会优于另一个数据模型，如何为一个特定的系统建立数据模型没有唯一的解决方案。

好模型的目标是将工程项目整个生存期内的花费减至最小，同时也会考虑到随时间推移系统可能发生的变化，因而设计时也要考虑能适应这些变化。

因此，将目光集中在最大限度地降低开发费用上是一个错误。

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

XML文档分为两类：

1. 以文档为中心的文档：这种文档结构不规则，内容比较零散，具有较多的混合内容，并且元素之间的顺序是有关的。这种文档常用来在网页上发布描述性信息、产品性能介绍和E-mail信息等。
2. 以数据为中心的文档：这种文档结构规则，内容同构，具有较少的混合内容和嵌套层次，人们只关心文档中的数据而并不关心数据元素的存放顺序。这种文档简称数据文档，常用来存储和传输Web数据

XML文档的存储方式：

1. 基于文件的存储方式
2. 数据库存储方式

---

6 物联网层次架构设计

物联网（Internet of Things，IoT）通过信息传感设备，按约定的协议，将任何物体与网络相连接，物体通过信息传播媒介进行信息交换和通信，以实现智能化识别、定位、跟踪、监管等功能。其三层结构如下：

1. 应用层：解决信息处理和人机交互问题，实现广泛智能化。（最顶层，离用户终端最近）
   • 例：应用服务、智能终端
   • 有时在应用层之后增加平台层（如操作系统、软件开发、设备管理平台、连接管理平台）
2. 网络层：用于传递信息和处理信息。（中间层）
   • 例：网络通信标准/协议
3. 感知层：用于识别物体、采集信息。（最底层）
   • 例：二维码标签和识读器、RFID标签和读写器、摄像头、GPS、传感器、M2M 终端、传感器网关等