实体基类体系与继承机制¶
本文讲清 OBPM 实体的**两条继承主线**与核心基类职责,不逐类罗列。架构总览见 [[../backend-architecture]];相关专题:[[form-field-hierarchy]]、[[workflow-node-hierarchy]]、[[dao-process-mechanism]]。
OBPM 的持久化实体分两条平行主线:
| 主线 | 根 | 存储方式 | 典型子类 |
|---|---|---|---|
| ValueObject 体系(旧、运行时数据) | cn.myapps.common.data.ValueObject |
手写 JDBC DAO(T_DOCUMENT、T_FLOWSTATERT 等静态表) |
FlowStateRT、NodeRT、ActorRT、UserVO、DomainVO |
| DesignTimeSerializable 体系(设计态定义) | cn.myapps.common.DesignTimeSerializable |
JAXB XML 落盘 workspace(.form、.flow 等) |
Form、BillDefiVO、Module、DataSource |
| (补充)JPA @Entity(新模块) | 无公共根(或 JPA @MappedSuperclass) |
Hibernate ddl-auto=update 建表 |
KMS FileEntity/FolderEntity、mc_message、ai_* |
1. ValueObject 主线¶
classDiagram
class Serializable
class ValueObject {
<<abstract, obpm-common>>
+String id
+int version
+String sortId
+String applicationid
+String domainid
+boolean lazyLoad
}
class AuthtimeValueObject {
<<abstract, obpm-core>>
}
class UserVO
class DomainVO
class DepartmentVO
class FlowStateRT
class NodeRT
class ActorRT
Serializable <|.. ValueObject
ValueObject <|-- AuthtimeValueObject
AuthtimeValueObject <|-- UserVO
AuthtimeValueObject <|-- DomainVO
AuthtimeValueObject <|-- DepartmentVO
ValueObject <|-- FlowStateRT
ValueObject <|-- NodeRT
ValueObject <|-- ActorRT
核心基类职责¶
| 基类 | 位置 | 职责 |
|---|---|---|
ValueObject |
obpm-common/.../data/ValueObject.java |
全平台**运行时实体根**:统一 id/version(乐观锁)/sortId/applicationid/domainid 五要素。id+domainid 构成多租户隔离的基础——每个实体天生知道自己属于哪个域、哪个应用 |
AuthtimeValueObject |
obpm-core/.../common/model/ |
认证域实体中间层:给 User/Department/Domain/UserGroup 等**组织架构类**实体追加认证场景公共字段(同时把体系从 common 桥接到 core) |
要点:
version字段配合静态表VERSIONS列做乐观并发控制。- 工作流运行态三剑客(
FlowStateRT/NodeRT/ActorRT)直接继承 ValueObject(不走 Authtime),因为它们是流程运行数据而非组织架构。 ObpmSystem是特例:继承UserVO,系统内置超级管理员单例。
2. DesignTimeSerializable 主线(workspace XML)¶
classDiagram
class Serializable
class DesignTimeSerializable {
<<interface, obpm-common>>
}
class FileSystemDesignTimeSerializable {
<<abstract, obpm-common>>
#String name
#String description
+getPath() String
+getUri() String
}
class Form
class BillDefiVO
class Module
class DataSource
Serializable <|.. DesignTimeSerializable
DesignTimeSerializable <|.. FileSystemDesignTimeSerializable
FileSystemDesignTimeSerializable <|-- Form
FileSystemDesignTimeSerializable <|-- BillDefiVO
FileSystemDesignTimeSerializable <|-- Module
FileSystemDesignTimeSerializable <|-- DataSource
核心基类职责¶
| 基类 | 位置 | 职责 |
|---|---|---|
DesignTimeSerializable(接口) |
obpm-common |
标记"可设计、可落盘"的契约 |
FileSystemDesignTimeSerializable |
obpm-common |
设计态实体的**公共骨架**:name/description 字段(带 @XmlJavaTypeAdapter(CDATA) 处理特殊字符)、getPath()/getUri() 计算 workspace 相对路径。路径规则封装在此——子类(如 Module)只覆写 getPath() 决定自己挂哪(/module/ 层级硬规则的实现处) |
机制:设计器保存任一资源时,AbstractFSDesignTimeDAO.save 按 getUri() 写 XML 到 workspace → 更新 url.index → Runtime 监听索引热加载。详见 [[../../workspace-mechanism/overview]](或原 design/workspace-structure-and-mechanism/)。
3. JPA 主线(新模块)¶
KMS 为代表:@MappedSuperclass FileObject(抽象,公共字段+复合主键 FileObjectId)→ FileEntity / FolderEntity 共表 KMS_FILEOBJECT(靠 TYPE 列区分子类语义)。message/ai 模块直接 @Entity,无公共根。
classDiagram
class IFile {
<<interface>>
}
class FileObject {
<<@MappedSuperclass, abstract>>
}
class FileEntity {
TYPE=文件
}
class FolderEntity {
TYPE=文件夹
}
class FileObjectId {
ID + VERSION 复合主键
}
IFile <|.. FileObject
FileObject <|-- FileEntity
FileObject <|-- FolderEntity
FileObject ..> FileObjectId : 嵌入主键
**共表+鉴别列**是 KMS 的刻意设计:文件与文件夹同构(都有父子层级),避免两张表互查。
4. 三线协同(一次表单保存)¶
flowchart TD
A[设计器: Form 对象<br/>DesignTimeSerializable 线] -->|"JAXB 落盘 .form XML"| B[workspace]
B -->|"url.index 热加载"| C[Runtime: Form 缓存]
C -->|建表| D[(TLK_ 动态表)]
E[用户填单] --> F[Document/Item<br/>ValueObject 线]
F -->|手写 DAO| D
F -->|启动流程| G[FlowStateRT/NodeRT/ActorRT<br/>ValueObject 线]
G -->|手写 DAO| H[(T_ 静态表)]
| 环节 | 继承线 | 存储 |
|---|---|---|
| 定义"表单长什么样" | DesignTimeSerializable | workspace XML |
| 存"用户填的数据" | ValueObject(Document 聚合 Item) | TLK_ 动态表(JDBC) |
| 记"流程走到哪" | ValueObject(RT 三剑客) | T_ 静态表(JDBC) |
| KMS/AI/Message 新业务 | JPA @Entity | 各自表(Hibernate) |