java自定义表单引擎-如何进入表单引擎

可视化表单建模是低代码/零代码平台的核心功能，业内对该功能有多种叫法：电子表单、表单可视化、表单驱动、表单引擎等，该组件主要由表单设计器、表单解析引擎、表单存储引擎三个部分构成，而表单解析引擎取决于表单存储引擎的技术方案，本文重点介绍表单设计器和表单存储引擎的技术方案选型。

一、表单设计器 1、FormMaking

FormMaking基于 Vue 的可视化表单设计器，赋能企业实现低代码开发模式；帮助开发者从传统枯燥的表单代码中解放出来，更多关注业务，快速提高效率，节省研发成本。

FormMaking使用基于 Vue 2.0 的桌面端组件库 Elemnet ，使用广泛，扩展方便。

2、Variant Form

VForm是一款基于Vue 2/Vue 3的低代码表单，支持Element UI、iView两种UI库，定位为前端开发人员提供快速搭建表单、实现表单交互和数据收集的功能。

VForm 3是一款基于Vue 3.x的低代码表单，支持Element PlusUI库，定位为前端开发人员提供快速搭建表单、实现表单交互和数据收集的功能。VForm 3全称为Variant Form 3，寓意为灵活的、动态的、多样化的Vue 3.x低代码表单。VForm 3由表单设计器VFormDesigner和表单渲染器VFormRender两部分构成，VFormDesigner通过拖拽组件方式生成JSON格式的表单对象，VFormRender负责将表单JSON渲染为Vue组件。

3、k-form-design

基于vue2和ant-design-vue实现的表单设计器，样式使用less作为开发语言，主要功能是能通过简单操作来生成配置表单，生成可保存的JSON数据，并能将JSON还原成表单，使表单开发更简单更快速。

4、form-create

form-create 是一个可以通过 JSON 生成具有动态渲染、数据收集、验证和提交功能的表单生成组件。支持3个UI框架（ElementUI、Iview/View-design、Ant-design-vue），并且支持生成任何 Vue 组件。内置20种常用表单组件和自定义组件，再复杂的表单都可以轻松搞定。

form-create-designer

二、表单存储引擎

低代码平台需要支持用户存储自定义数据，因为每个应用所需的表、字段、以及关系都是不一样的。自定义数据存储是后端低代码最重要的功能，使用什么方案将直接影响这个产品的适用范围，目前我们已知有4种方案，每种都有自己的优缺点。

方案 1：直接使用关系型数据库

这个方案的原理是将数据模型的可视化操作转成数据库 DDL，比如添加了一个字段，系统会自动生成表结构变更语句：

ALTER TABLE 'blog' ADD 'title' varchar(255) NULL;

这个方案的优点是：

该方案的缺点是：

尽管这个方案有缺点java自定义表单引擎，这些缺点通过一些机制或管理手段可以规避，重要的是该方案的优点很突出，因此国内大部分低代码平台选择了这个方案，因为能支持企业级复杂应用需求、继承现有数据资产是非常重要的。

方案 2：使用文档型数据库

文档型数据库不需要预先定义表结构，因此它很适合用来存储用户自定义数据，这个方案实现起来比较简单，以 MongoDB 为例，可以这样做：

用户创建一个自定义表的时候，系统就自动创建一个 collection，所有这个表的数据都存在这个 collection 里。用户新增字段的时候，就随机分配一个 fileId，后续对这个字段的操作都自动映射到这个 fileId 上，用 fileId 的好处是用户重命名字段后还能查找之前的数据，因为所有数据查询底层都基于这个 fileId。查询的时候先找到对应的 collection，再通过 meta 信息查询字段对应的 fileIdjava自定义表单引擎，使用这个 fileId 来获取数据。

这个方案的优点是实现简单，用户体验可以做得更好，是目前大部分零代码平台的选择，使用这个方案的产品也很好识别，只要看一下它的私有部署文档，如果有要求装 MongoDB 就肯定是。明道云低代码平台就是基于MongoDB的实现方案。

这个方案有显著缺点：

它的最大特点是界面编辑和数据存储是统一的，当你拖入文本框到页面后就会自动创建对应的字段，不需要先创建数据模型再创建界面，因此用起来更简单。

方案 3：使用关系型数据库行转列

这是很多可扩展平台里使用的技术，比较典型的是 WordPress，它的扩展性很强，装个扩展就能变成电商网站。而整个 WordPress 只有12个表，它是怎么做到的？方法是靠各种 meta 表，比如用于扩展文章的wp_postmeta表结构如下:

CREATE TABLE wp_postmeta (

meta_id bigint(20) unsigned NOT NULL auto_increment,

post_id bigint(20) unsigned NOT NULL default '0',

meta_key varchar(255) default NULL,

meta_value longtext,

PRIMARY KEY (meta_id),

KEY post_id (post_id),

KEY meta_key (meta_key)

) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

其中的关键就是meta_key和meta_value这两个字段，相当于将数据库当 KV 存储用了，因此可以任意扩展字段名及值。

这个方案的优点是实现简单，但缺点也很明显：

这个方案主要用于成熟项目的扩展，比如在 CRM 产品中允许用户扩展字段，但因为性能较低，并不适合通用低代码平台。

方案 4：使用关系数据库宽表

早期数据库不支持 JSON 字段的时候，有些开发者会预留几个列来给用户扩展自定义属性，比如在表里加上 ext1、ext2、ext3 字段，让用户可以存 3 个定制数据，基于这个原理我们可以进一步扩展，通过预留大量列来实现应用自定义存储。

这个方案最早出现在，具体细节可以阅读它技术文档：。

实现它有两个关键点：元数据、预留列，这里简单说明一下原理，首先系统预先创建一个 500 列的表，比如就叫 data：

也可以创建更多，但注意有的数据库对列的数量有限制，比如 MySQL 最多是4096列。

上面的 data 表里主要有 4 类字段：

在这个 table_fields 表里：

要完全实现这个方案还有很多细节问题得解决，由于篇幅原因这里不详细介绍，感兴趣可以阅读前面提到的技术白皮书，这里列举其中几个问题：

这个方案比前面几个方案的优点是：

但它也有许多缺点：

我认为这个方案适合某些业务领域SaaS 类产品，可适用的业务领域不多，不具备通用性，我不看好这个方案在国内的发展。Salesforce 的成功不单单是技术，跟当时的所处的IT环境、行业选择、产品定位、商务推广等多个方面都有关系。

参考：

Multi Tenant Architecture - developer.force.com

从实现原理看低代码 - 知乎

云程 | 云BPM,云程BPM,低代码平台,低代码开发平台,开源流程引擎,Camunda,flowable,业务流程管理,activiti,智能表单,电子表单,可视化开发,零代码开发,基础平台,流程PaaS,流程SaaS