表单引擎三大范式与驰骋双轨实现

原创于 2026-06-20 12:13:18 发布 · 160 阅读

6 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#开源驰骋低代码 #工作流引擎

驰骋表单引擎同时被 2 个专栏收录

105 篇文章

订阅专栏

表单引擎

3 篇文章

订阅专栏

表单引擎三大设计范式

出品：驰骋低代码 BPM / CCFlow
文档版本：2026-06
依据代码：Vue3/src、CCFlow/Components/BP.En30、CCFlow/Components/BP.WF
在线演示：http://ccflow.org
代码下载：http://ccflow.org

驰骋低代码的划分标准与主张

本文所阐述的「表单三大设计范式」划分标准，出自驰骋低代码 BPM 团队的技术归纳与产品主张，并非业界唯一分类方式，但经二十年 CCFlow/JFlow 工程实践反复验证。

驰骋认为：企业软件中的「表单」问题，本质是如何把数据结构变成可交互的界面。三十年来，业界围绕这一问题形成了三种典型路径——我们把它们归纳为：

范式	规则载体	驰骋产品映射
基于文件	`.html`、`.jsp`、`.aspx` 等页面/模板文件	嵌入式表单、开发者表单、VSTO 模板等补充能力
基于数据库	元数据表（字段、布局、扩展逻辑）	低代码表单（五类设计器）
基于规则	实体类 `EnMap`、ORM 元数据	高代码表单（Search / EnOnly / Group 三组件）

驰骋的核心主张可以概括为三句话：

同一道题，多个解——三种范式都能完成表单的采集、校验、存储与展现；没有绝对的对错，只有角度与立场不同。
双轨并行，而非二选一——驰骋表单引擎同时提供「低代码表单」（基于数据库）与「高代码表单」（基于规则），按场景选用、混搭共存。
统一 ORM 底座——无论低代码还是高代码，字段语义均源自 BP.En30 的 Map / Attr 体系，降低范式切换成本。

下文从区别、对比、应用场景、适用人群、优缺点五个维度，逐一展开三种范式，并说明驰骋的具体落地方式。

一、三种范式概览：同一道题，三种解法

如同一道数学题可以有代数解、几何解与图解法，表单实现也有三条成熟路径。选型取决于：谁维护、变更多不多、逻辑有多复杂、是否需要多端统一——而非哪种范式「更先进」。

二、范式一：基于文件的表单

2.1 核心机制

这是传统、也是最直觉的解决方案：由数据模型驱动，通过代码生成器或手工编写，产出 .html、.jsp、.aspx 等格式的页面文件；文件内容包含列表列定义、表单字段标签、输入控件及页面脚本。

数据模型（表结构） → 生成器 / 手工编码 → 页面文件 → Web 容器 → 浏览器渲染

每个表单对应一份（或一组）文件。修改布局或字段，通常意味着改文件、重新部署。

2.2 从自身角度看：优缺点

优点	说明
性能直接	无运行时元数据解析，页面即最终产物，首屏与交互延迟可控
技术栈成熟	与 Servlet、ASP.NET、PHP 等宿主框架天然契合，人才储备充足
版式自由度极高	HTML/CSS/JS 或 Office 模板可任意排版，不受设计器控件集限制
离线/本地能力强	VSTO 等方案可调用本机 Office，适合复杂排版与公式计算
投资保护	已有 JSP/ASPX 页面可直接复用，无需推倒重来

缺点	说明
变更成本高	字段增删改需动文件、走发布流程，难以「配置即生效」
多端维护负担	PC 与移动端往往需两套文件或额外适配层
逻辑分散难治理	级联、显隐等交互散落在页面脚本中，跨表单复用困难
业务人员无法自助	依赖开发团队，实施周期长，响应业务变化慢
与流程引擎耦合紧	每个节点若独立页面，版本管理与权限统一成本高

2.3 应用环境

表单结构极少变更，一次开发长期使用；
企业已有大量 JSP/ASP.NET/PHP 遗留页面，需平滑接入 BPM；
版式要求极高，需借助 Word/Excel 排版与公式（公文、报表、合同）；
对运行时元数据解析有性能敏感要求，愿以维护成本换取执行效率；
团队以传统 Web 开发为主，尚未引入低代码平台。

2.4 适用人群

角色	匹配度
Java/.NET 传统 Web 开发工程师	★★★★★
有 Office 宏/VSTO 经验的实施顾问	★★★★☆
业务分析师 / 流程管理员	★☆☆☆☆
零基础业务人员	★☆☆☆☆

2.5 在驰骋体系中的位置

驰骋主路径已演进为「数据库元数据 + 规则代码」双轨，但文件范式作为补充能力保留：

能力	`FrmType`	说明
嵌入式表单	`Url = 3`	节点绑定外部 URL，第三方页面即表单
开发者表单	`Develop = 8`	HTML 模板存 `Sys_MapData.HtmlTemplateFile`
VSTO Excel / Word	`6` / `61`	Office 文件为模板，本地程序加载展现

代码锚点：Vue3/src/WF/Admin/EnumLab.ts → FrmType 枚举。

三、范式二：基于数据库的表单（驰骋低代码表单）

3.1 核心机制

通过可视化设计器将表单描述写入数据库；运行时由通用解析器读取元数据，动态渲染 PC 端、移动端、列表查询与表单填写界面。

驰骋低代码表单遵循四步链路：

梳理规则 → 定义规则（设计器） → 存储规则（数据库） → 解析规则（解析器）

表单元素 vs 交互逻辑

驰骋将「用户看到什么」与「控件如何联动」明确拆分：

概念	含义	存储位置	示例
表单元素	用户可见的控件	`Sys_MapAttr`	文本框、单选、多选、附件、子表、图标、日期、评分……
交互逻辑	控件之间的行为规则	`Sys_MapExt`	下拉框级联、单选控制显隐、自动计算、Pop 弹窗选值……

表单元素类型见 FoolFormDesigner/props/database/DatabaseFormItem.ts 的 DBEnums 枚举；交互逻辑在设计器属性面板配置，如 GPE_ActiveDDL（级联联动）、GPE_AutoFull（自动计算）。

元数据表结构（节选）

表名	职责	代码模块
`Sys_MapData`	表单主档：ID、名称、类型、存储表	`BP.WF`
`Sys_MapAttr`	表单元素定义	`BP.En30`
`Sys_GroupField`	分组 / 页签 / 章节	`BP.WF`
`Sys_MapDtl`	子表（从表）	`BP.WF`
`Sys_MapExt`	交互逻辑扩展	`BP.En30`
`Sys_FrmAttachment`	附件控件	`BP.WF`

解析器在不同场景统一加载上述元数据：

场景	解析入口
PC 表单填写	`WF_CCForm.cs` + 前端表单组件
移动端	`CCMobile` 对应组件
列表查询	`SearchBill.vue` 等单据列表
从表编辑	`MapDtl` + 经典表单 / 表格模式

3.2 从自身角度看：优缺点

优点	说明
业务人员可自助	拖拽设计器即可增删字段、调布局，无需编译发布
一份元数据，多端复用	同一套 `MapAttr` 驱动 PC、移动、列表，避免重复维护
元素与逻辑分离	控件归 `MapAttr`，联动归 `MapExt`，结构清晰、便于治理
与 BPM 深度集成	流程节点、单据、权限、附件开箱即用
实施交付快	标准 CRUD 表单可在数小时内完成配置上线
导入导出可迁移	元数据可打包在不同环境间迁移

缺点	说明
版式受设计器约束	极端自由排版不如纯 HTML/Office 灵活
复杂逻辑有天花板	超复杂算法、外部系统集成更适合高代码
运行时解析开销	相较静态页面，多一层元数据读取与组装
版本管理偏库表	精细 diff 不如 Git 管理代码直观（可辅以导入导出）
设计器学习成本	业务人员需理解元素、逻辑、从表等概念

3.3 应用环境

流程审批表单、业务单据：字段与布局频繁调整，需业务人员参与；
多端统一：同一表单在 PC 与移动端同步展现；
标准化录入场景：请假、报销、采购、维修单等 CRUD 为主；
实施型项目：交付周期紧，顾问现场配置即可验收；
需要与驰骋流程引擎、单据引擎、组织结构联动的内置场景。

3.4 适用人群

角色	匹配度
业务分析师 / 流程管理员	★★★★★
BPM 实施顾问	★★★★★
企业信息化管理员	★★★★☆
前端开发工程师（做扩展配置）	★★★☆☆
仅需写复杂算法的后端架构师	★★☆☆☆

3.5 驰骋低代码表单：五类设计器

驰骋低代码表单针对五类典型应用场景提供专用设计器，入口为 GPN_NewFrm（新建表单向导）：

序号	设计器	`FrmType`	应用场景	代码路径
1	经典表单设计器	`0` FoolForm	常规流程表单、单据；拖拽、栅栏格、丰富控件	`Vue3/src/WF/Admin/FoolFormDesigner`
2	开发者表单设计器	`8` Develop	复杂 HTML 排版，富文本随心所欲	`HtmlTemplateFile` 存储
3	章节表单设计器	`10` ChapterFrm	合同、申报书、操作手册等章—节—内容大文档	`Vue3/src/WF/Admin/ChapterFrmDesigner`
4	VSTO Excel 设计器	`6` VSTOForExcel	复杂计算、保持 Excel 样式与公式	`DesignerVSTO`
5	VSTO Word 设计器	`61` VSTOForWord	公文、合同等 Word 版式文档	`DesignerVSTO`

五类设计器共性：设计成果落入数据库（或关联模板存储），运行时由平台解析器统一加载。

经典表单特点（GPE_FrmType）：字段可拖拽排序、栅栏格布局、文本属性可切换为单选/多选/附件/地图等丰富控件。

章节表单结构：一个分组即「章」，每个字段默认为大块文本即「节」，适合层次化文档填报。

四、范式三：基于规则的表单（驰骋高代码表单）

4.1 核心机制

不再将字段逐条写入数据库，而是在代码中声明实体规则，借助 ORM 的 Map / Attr 体系定义：

物理表、主键、字段属性；
查询条件、列表列、隐藏条件；
主从关系、分组、权限（UAC）；
生命周期钩子（beforeInsert / beforeUpdate 等任意业务逻辑）。

驰骋高代码表单三步链路：

梳理规则 → 定义规则（.ts / .cs 实体类） → 解析规则（Search / EnOnly / Group）

无独立「存储到元数据表」环节——规则载体是代码仓库中的实体类文件。

示例：`Student.ts`

官方演示实体 Vue3/src/App/Demo/Student.ts 展示了声明式写法：

export class Student extends EntityNoName {
  public override get EnMap() {
    const map = new Map('Demo_Student', '学生');

    map.AddGroupAttr('基本字段');
    map.AddTBStringPK('No', null, '编号', true, true, 4, 4, 80);
    map.AddTBString('Name', null, '名称', true, false, 0, 200, 80);
    map.AddImgAth('AthICon', '头像', true, false, 3);

    map.AddGroupAttr('枚举');
    map.AddRadioBtn('XB', 0, '性别', true, true, 'XB', '@0=女@1=男@2=未知');
    map.AddCheckbox('Interest', '', '爱好', true, true, '', '@0=音乐@1=编程...');
    map.AddDDLEntities('BanJiNo', null, '班级外键', new BanJi(), true);

    map.AddSearchAttr('XB', 150);
    map.AddSearchHidden('BanJiNo', 'in', '001,003,004');

    return map;
  }

  override async beforeInsert(): Promise<boolean> {
    this.RecNo = WebUser.No;
    this.RecName = WebUser.Name;
    return true;
  }
}

实体类即「表单说明书」：AddTBString 定义字段，AddSearchAttr 定义查询列，beforeInsert 承载任意复杂逻辑。

4.2 从自身角度看：优缺点

优点	说明
逻辑表达无上限	TypeScript/C# 可写任意算法、API 集成、复杂校验
Git 版本管理	实体类随代码仓库演进，diff、分支、Code Review 成熟
一份实体，多种视图	同一 `EnMap` 驱动 Search / EnOnly / Group，ORM 多态
类型安全与 IDE 支持	补全、重构、静态检查提升长期维护效率
与低代码共享 ORM 语义	`Map.AddTBString` 与 `Sys_MapAttr` 字段语义一致，可互转
适合平台级功能	组织结构、权限、系统配置等核心模块的首选

缺点	说明
业务人员无法直接改	字段调整需开发改代码、编译发布
实施响应慢于低代码	简单 CRUD 用高代码反而过度工程化
前端 UI 受解析组件约束	布局自由度低于手写 Vue 页面
学习曲线	需掌握 ORM、`EnMap` API、实体生命周期
变更生效需发布	不像设计器配置可即时生效

4.3 应用环境

系统管理、组织结构、权限配置等核心平台功能；
逻辑复杂、算法密集的业务（定价引擎、合规校验、多系统对接）；
长期演进、需严格版本管理的主数据模块；
统计分析、分组报表类页面（Group 组件）；
开发团队有 TypeScript/C# 能力，追求代码即文档的工程文化。

4.4 适用人群

角色	匹配度
全栈 / 前端开发工程师	★★★★★
平台架构师 / 技术负责人	★★★★★
有 ORM 经验的后端工程师	★★★★☆
BPM 实施顾问（做标准配置）	★★☆☆☆
零基础业务人员	★☆☆☆☆

4.5 驰骋高代码表单：三个解析组件

同一实体类（如 TS.Demo.Student）通过三个固定组件覆盖三类应用场景：

组件	路径	应用场景	适用人群	调用方式
Search.vue	`Vue3/src/WF/Comm/Search.vue`	多条件查询 + 结果列表；焦点字段打开详情	业务用户日常检索	`GloComm.UrlSearch('TS.Demo.Student')`
EnOnly.vue	`Vue3/src/WF/Comm/EnOnly.vue`	单条新增/编辑/查看；分组、从表、附件	业务用户录入维护	`GloComm.UrlEnOnly('TS.Demo.Student', '001')`
Group.vue	`Vue3/src/WF/Comm/Group.vue`	按维度分组汇总、统计分析	管理人员分析决策	`GloComm.UrlGroup('TS.Demo.Student')`

Search.vue：结合 EnCfg 配置查询列、关键字、日期段、外键筛选，是主数据列表默认入口。

EnOnly.vue：读取 EnMap 分组与字段，支持页签/分组栏、从表嵌入、字段联动显隐（UIkeyRef）、工具栏方法。

Group.vue：在 Search 能力上增加分组维度，适合分类汇总与统计钻取。

后端 ORM 支撑：CCFlow/Components/BP.En30 提供 Entity、Map、Attr、UAC、RefMethod 等核心能力；CCFlow/Components/BP.WF 提供流程与表单服务集成。

五、三种范式横向对比

5.1 核心维度对比

维度	基于文件	基于数据库（低代码）	基于规则（高代码）
规则载体	`.html` / `.jsp` / `.aspx` / Office 模板	`Sys_MapAttr` 等元数据表	`.ts` / `.cs` 实体 `EnMap`
定义方式	生成器 / 手工编码	可视化设计器拖拽	代码声明 `Map.AddXXX`
变更生效	改文件 + 部署	设计器保存，通常即时生效	改代码 + 编译发布
多端支持	需多套文件或适配	一份元数据，解析器适配	一份实体，三组件适配
复杂逻辑	页面脚本分散	`MapExt` + 事件配置	任意 TS/C# 代码
版式自由度	最高	受设计器控件集约束	受解析组件布局约束
驰骋产品	嵌入式 / VSTO / 开发者表单	低代码表单（五类设计器）	高代码表单（三组件）

5.2 应用场景对比

场景	推荐范式	理由
流程审批、标准单据录入	基于数据库	业务可自助调字段，实施快
合同 / 项目申报大文档	基于数据库（章节表单）	章—节结构天然匹配
复杂 Excel 计算报表	基于数据库（VSTO Excel）	复用 Office 公式与样式
已有 JSP/ASP 遗留系统	基于文件（嵌入式）	保护投资，URL 接入即可
系统管理、组织权限	基于规则	逻辑复杂，需 Git 管理
主数据维护 + 列表查询	基于规则（Search + EnOnly）	一份实体，两种视图
统计分析、分组报表	基于规则（Group）	与 Search 共用实体定义
超复杂业务算法	基于规则	代码表达无上限

5.3 适用人群对比

人群	基于文件	基于数据库	基于规则
传统 Web 开发工程师	主力	辅助	可转型
BPM 实施顾问	接遗留	主力	扩展开发
业务分析师 / 流程管理员	不参与	主力	不参与
全栈 / 平台开发工程师	接遗留	配置扩展	主力
企业信息化管理员	不参与	主力	不参与

5.4 优缺点一句话总结

范式	一句话
基于文件	性能与版式最强，变更与治理最弱——适合稳定、遗留、Office 重度场景
基于数据库	自助与交付最强，复杂逻辑有天花板——适合流程表单、标准单据、实施型项目
基于规则	灵活与工程化最强，业务自助最弱——适合平台功能、复杂逻辑、长期演进模块

六、驰骋表单引擎双轨实现

驰骋并非在三种范式中「押注其一」，而是将基于数据库与基于规则作为主力双轨，基于文件作为补充能力，统一在 BP.En30 ORM 底座之上。

┌─────────────────────────────────────────────────────────────┐
│                    驰骋表单引擎（CCFlow）                      │
├──────────────────────────┬──────────────────────────────────┤
│   低代码表单（基于数据库）   │      高代码表单（基于规则）         │
│   五类设计器              │      三个解析组件                  │
│   → 元数据入库            │      → 实体 EnMap 在代码中          │
│   → WF_CCForm 解析        │      → Search / EnOnly / Group   │
├──────────────────────────┴──────────────────────────────────┤
│   补充：嵌入式 / 开发者 HTML / VSTO（基于文件）               │
├─────────────────────────────────────────────────────────────┤
│   统一底座：BP.En30 ORM + BP.WF 工作流/表单服务 + Vue3/src   │
└─────────────────────────────────────────────────────────────┘

低代码轨道：GPN_NewFrm 选择设计器 → 元数据写入 Sys_MapData / Sys_MapAttr / Sys_MapExt → WF_CCForm 与前端组件解析 → PC/移动/列表展现。

高代码轨道：编写 Student.ts 等实体类 → Search.vue / EnOnly.vue / Group.vue 读取 EnMap → 列表/详情/分析展现。

混搭示例：流程节点用低代码经典表单采集审批数据，后台主数据用高代码 Student 实体维护——同一平台、同一 ORM 语义，不同范式各展所长。

七、结语：立场不同，解法不同

表单实现的三大范式——基于文件、基于数据库、基于规则——是驰骋低代码 BPM 对三十年企业软件实践的技术归纳。

它们解决的是同一个问题：让数据可靠地流入业务系统，并以合适的形态呈现给用户；
它们代表不同的立场：谁维护表单、变更有多频繁、逻辑有多复杂；
它们没有绝对优劣：如同同一道题有多个解，选型取决于角度，而非道德高低。

驰骋的主张是：在同一引擎内提供低代码与高代码双轨，按场景自由切换，而不必更换平台。 五类设计器赋能业务与实施，三个解析组件赋能开发，统一 ORM 底座降低范式切换成本——这是驰骋低代码 BPM 表单引擎的核心竞争力。

附录：关键代码索引

主题	路径
表单类型枚举	`Vue3/src/WF/Admin/EnumLab.ts` → `FrmType`
新建表单向导（五类设计器）	`Vue3/src/WF/Admin/FrmLogic/GPN_NewFrm.ts`
经典表单设计器	`Vue3/src/WF/Admin/FoolFormDesigner/`
章节表单设计器	`Vue3/src/WF/Admin/ChapterFrmDesigner/`
表单元素类型	`FoolFormDesigner/props/database/DatabaseFormItem.ts`
高代码演示实体	`Vue3/src/App/Demo/Student.ts`
Search / EnOnly / Group	`Vue3/src/WF/Comm/`
URL 封装	`Vue3/src/WF/Comm/GloComm.ts`
后端表单解析	`CCFlow/Components/BP.WF/HttpHandler/WF_CCForm.cs`
ORM 核心	`CCFlow/Components/BP.En30/`
高代码开发详解	`doc/低代码部分/面向模式编程思想-的高代码开发.md`