层次式架构设计
理论与实践
Layered Architecture Design — Theory and Practice
层次式体系结构概述
Overview一、定义
软件体系结构为软件系统提供了结构、行为和属性的高级抽象,由构成系统的元素描述这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
层次式体系结构设计是一种常见的架构设计方法,它将系统组成为一个层次结构,每一层为上层服务,并作为下层客户。在一些层次系统中,除了精心挑选的输出函数外,内部的层接口只对相邻的层可见。
层次式体系结构的每一层最多只影响两层,同时只要给相邻层提供相同的接口,也允许每层用不同的方法实现,这种方式也为软件重用提供了强大的支持。
二、层次式应用的组成
大部分的应用会分成四层结构:
| 层次 | 别称 | 职责 |
|---|---|---|
| 表现层 | 展示层 | 用户交互界面,处理输入与输出展示 |
| 中间层 | 业务层 | 实现核心业务逻辑 |
| 访问层 | 持久层 | 对数据源的访问与操作封装 |
| 数据层 | — | 存储应用数据(数据库/文件等) |
三、特点与注意事项
每层中的组件只负责本层的逻辑,组件的划分也很容易明确组件的角色和职责,比较容易开发、测试、管理和维护。
污水池反模式 Architecture Sinkhole Anti-pattern
请求流简单地穿过几个层,每层里面基本没有做任何业务逻辑,或者只做了很少的业务逻辑。例如一些 Java EE 案例中,业务逻辑层只是简单地调用了持久层的接口,本身没有业务逻辑。
应用变得庞大
分层架构可能会让应用整体规模变得庞大,引入额外的复杂度。
表现层框架设计
Presentation LayerMVC / MVP / MVVM 三种模式的区别与演进关系是高频考点,务必掌握 View 与 Model 之间的耦合方式差异。
一、MVC 模式
MVC 是一种软件设计模式。MVC 把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离,形成了 3 个核心模块。
| 组件 | 职责 |
|---|---|
| Controller 控制器 | 接受用户的输入,并调用模型和视图去完成用户的需求 |
| Model 模型 | 应用程序的主体部分,表示业务数据和业务逻辑 |
| View 视图 | 用户看到并与之交流的界面 |
- 允许多种用户界面的扩展
- 易于维护
- 易于构建功能强大的用户界面
- 增加应用的可扩展性、强壮性、灵活性
二、MVP 模式
在 MVP 模式中,Model 提供数据,View 负责显示,Controller/Presenter 负责逻辑的处理。MVP 不仅避免了 View 和 Model 之间的耦合,还进一步降低了 Presenter 对 View 的依赖。
- 模型与视图完全分离,可以修改视图而不影响模型
- 所有的交互都发生在一个地方 —— Presenter 内部,因此可以更高效地使用模型
- 可以将一个 Presenter 用于多个视图,而不需要改变 Presenter 的逻辑(视图的变化总是比模型频繁)
- 如果把逻辑放在 Presenter 中,就可以脱离用户接口来测试这些逻辑(单元测试)
三、MVVM 模式
MVVM 和 MVC、MVP 类似,主要目的都是为了实现视图和模型的分离。不同的是 MVVM 中,View 与 Model 的交互通过 ViewModel 来实现,也就是 View 和 Model 不能直接通信,两者的通信只能通过 ViewModel 来实现。
ViewModel 是 MVVM 的核心,通过 DataBinding 实现 View 与 Model 之间的双向绑定,其内容包括:
中间层框架设计
Middle Layer一、业务逻辑层组件设计
业务逻辑层组件分为接口和实现类两个部分。
- 接口:用于定义业务逻辑组件,定义业务逻辑组件必须实现的方法 —— 是整个系统运行的核心
- 实现:通常按模块来设计业务逻辑组件,每个模块设计一个业务逻辑组件
- 基础:每个业务逻辑组件以多个
DAO (Data Access Object)组件作为基础,从而实现对外提供系统的业务逻辑服务
二、业务逻辑层工作流设计
工作流管理联盟 (Workflow Management Coalition, WFMC) 将工作流定义为:业务流程的全部或部分自动化,在此过程中,文档、信息或任务按照一定的过程规则流转,实现组织成员间的协调工作以达到业务的整体目标。
三、业务逻辑层实体设计
逻辑层实体提供对业务数据及相关功能的状态编程访问。
- 业务逻辑层实体可以使用具有复杂架构的数据来构建,这种数据通常来自数据库中的多个相关表
- 业务逻辑层实体数据可以作为业务过程的部分
I/O 参数传递 - 业务逻辑层实体是可序列化的,以保持它们的当前状态
四、业务逻辑层框架
业务逻辑框架位于系统架构的中间层,是实现系统功能的核心组件。采用容器的形式,便于系统功能的开发、代码重用和管理。在业务容器中,业务逻辑是按照 Domain Model — Service — Control 思想来实现的。
| 组成部分 | 说明 |
|---|---|
| Domain Model 领域模型 | 仅仅包含业务相关的属性的领域层业务对象 |
| Service 服务 | 业务过程实现的组成部分,是应用程序的不同功能单元,通过在这些服务之间定义良好的接口和契约联系起来 |
| Control 服务控制器 | 服务之间的纽带,不同服务之间的切换就是通过它来实现的 |
数据访问层设计
Data Access Layer一、数据访问模式(5 种)
数据访问模式有 5 种,分别是:在线访问、Data Access Object、Data Transfer Object、离线数据模式、对象/关系映射。
| 模式 | 英文/缩写 | 核心特征 |
|---|---|---|
| 在线访问 | Online |
最常用的方式。访问占用一个数据库连接,读取数据,每个数据库操作都会通过这个连接不断地与后台的数据源进行交互 |
| 数据访问对象 | DAO |
标准 J2EE 设计模式,将底层数据访问操作与高层业务逻辑分离。典型实现含:DAO 工厂类、DAO 接口、实现 DAO 接口的具体类、数据传输对象 |
| 数据传输对象 | DTO |
EJB 设计模式之一。DTO 是一组对象或容器,需要跨越不同的进程或网络的边界来传输数据 |
| 离线数据模式 | Offline |
以数据为中心,数据从数据源获取后按某种预定义结构存放在系统中,成为应用的中心。各种操作独立于与后台数据源之间的连接或事务 |
| 对象/关系映射 | ORMO/R Mapping |
利用工具或平台将应用程序中的数据↔关系数据库记录互相转换,便于以对象方式操作 |
二、工厂模式在数据访问层的应用
定义一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
数据访问层可能会处理对多种数据库的操作,因此需要:
- 首先定义一个操纵数据库的接口
- 然后根据数据库的不同,由类工厂决定实例化哪个类
三、ORM、Hibernate 与 CMP 2.0 设计思想
ORM (Object-Relation Mapping) 在关系型数据库和对象之间作一个映射。这样在具体操纵数据库时,就不需要再去和复杂的 SQL 语句打交道,只要像平时操作对象一样操作即可。
是一个功能强大、可以有效进行数据库数据到业务对象的 O/R 映射 方案。Hibernate 推动了基于普通 Java 对象模型(POJO),用于映射底层数据结构的持久对象的开发。
XML Schema
XML Schema 用来描述 XML 文档合法结构、内容和限制,提供丰富的数据类型。
四、事务处理设计 · ACID 原则
事务必须服从 ISO/IEC 所制定的 ACID 原则。
五、连接对象管理设计
建立一个数据库连接池,提供一套高效的连接分配、使用策略,保证了数据库连接的有效复用。
数据架构规划与设计
Data Architecture一、数据库设计与类的设计融合
对类和类之间关系的正确识别是数据模型的关键所在。
- 将工程项目整个生存期内的花费减至最小
- 考虑到随时间的推移系统将可能发生的变化
- 设计时也要考虑能适应这些变化
二、数据库设计与 XML 设计融合
XML 文档的存储方式有两种:
物联网层次架构设计
IoT Architecture物联网三层架构:感知层 → 网络层 → 应用层,类比人体则是 皮肤五官 → 神经大脑 → 社会分工。
应用层是物联网与行业专业技术的深度融合,结合行业需求实现行业智能化。
网络层将感知层获取的信息进行传递和处理。包括:
感知层主要功能是识别对象、采集信息。包括: