低代码平台的各种方案总结

概述

低代码/无代码平台(以下简称平台)这两年突然呈爆发状态,各种平台雨后春笋般冒出,但究其根本,具体的形式都大同小异,基本可以总结为四类,表单类型、页面区块类型、表格(Excel)类型、类语言级类型。

以下对这几种类型进行大体描述,不涉及细节,如果疏漏,欢迎交流。

如果对细节感兴趣的,请关注我,我后续还会再对各种类型进行具体描述。

一、表单类型

表单类型是平台最常见的一种形式

表单的核心为表单编辑器,流程编辑器,部分平台还有业务流编辑器(对数据的增删改流程进行后续操作),有的平台业务编辑器与流程编辑器是一体的。

这类平台由表单编辑器出发,根据表单组件的类型直接生成列表页,由其中的特殊组件(例如子表组件,关联数据组件)定义关联关系。

这类平台的列表页面一般比较固定,基本上每一种页面类型都需要定向(用代码)扩展。

在数据模型有了之后,一般由一个可视化数据编排工具,例如ETL,进行数据的分析,生成图表

图表展示页一般由一个可拖拽的布局器去引用生成的图表

此类型一般用在一些比较简单的后台数据管理、分析等场景,缺少一些更多场景的灵活性

二、页面区块类型

以页面为单元进行编排

直接从菜单出发,每新增一个菜单就是一个页面,所有的数据建模都来自于页面上存在的部分。

其核心为页面编辑器,组件列表,以及一个逻辑编排器。

页面编辑器中,由列表或者表单等形成数据建模,各个组件之间的逻辑关系,直接被解析为数据模型之间的关联。

页面上所有的部分都被解释为组件,可以自建数据模型,也可以引用其他的模型。

此类平台,弱化数据建模(后端逻辑)的独立性,直接从菜单(或者路由)作为起点,一切的逻辑都收缩页面上存在。

只要页面上的组件(包括有一定业务属性的组件)足够地丰富,逻辑编排的方式足够地多,那么可覆盖的场景就越广。

此类型市面上也比较多,各类大屏编辑器也属于这一类型,其能力强依赖于其组件的丰富程度和逻辑编排能力的完整度。

三、表格(Excel)类型

直接以表格进行建模,利用Excel强大的函数公式能力。

这一类平台在几年前比较常见,现在的流行度逐渐在降低了

直接以一张Excel表作为数据模型,定义每一列是什么意思

所有的表单、表格、流程等,都表现为一个Excel表

需要扩充部分动态的公式,甚至数据表之间的影响公式

权限、组织、人员、菜单等都放在外面,其数据也可以由Excel管理

由于Excel的流行性,这类平台的上手难度较低,尤其是对Excel比较熟悉的用户来说,只需要稍微学习一点新的公式和编排逻辑即可上手

但是同样,由于这类平台过于依赖于Excel,想做更复杂业务的时候,需要用户对Excel的复杂功能和业务抽象逻辑都有极深地了解才能继续,无形中的学习成本实际上是极高的

同时,由于对Excel的依赖性,也丧失了一部分页面上的灵活性。

这类平台常用于一些本身业务就依赖于Excel,同时对单据还原度要求比较高的场景

四、类语言级类型

这类平台比较少,严格来说已经快脱离低代码平台的范畴了

这类平台将所有的操作都细化到一个最小单元,几乎与写代码等同,但是更强化可视化编排这个能力

一般来说这类平台比较像“古老“的VB语言,将所有的组件都拆分为 属性、行为、事件

然后用一个可视化语法树的形式,允许你对各个组件的事件进行捕获,然后执行一些其他的行为

数据处理等,也是一个组件,主要用于可视化编排逻辑使用

对于后端的逻辑处理也类似,提供几个原生的系统能力组件,在可视化语法树中进行逻辑编排调用

只要逻辑单元,系统能力单元,组件单元足够丰富,“理论上”可以做到代码能做的所有功能( 底层能力除外 )

这类平台一般会提供完整的入门方案,生态市场,扩展文档,调试流程、发布流程等,如一门语言一般

可以说是一个可视化写代码的方式

上手难度较高,需要一定的编码逻辑基础才能上手,但是比较学一门语言的难度,还是要低一些的

总结

  1. 所有平台都是在将代码过程分块后进行某个方向的抽象,并进行可视化逻辑编排,将最细节的那一部分代码留在组件或者逻辑块内部,因此,这四种类型也可以认为是四种逻辑抽象的方向。
  2. 所有平台,都无法完全地解决所有的问题,其更像是一个同类业务模型的高级抽象,以便在短时间内解决更多类似的问题,甚至可以自动化地解决一些问题( 如果样本足够多,我相信可以做到根据描述生成一部分的功能出来 )。
  3. 大多数的平台都无法绕过元数据(数据建模)建立这一关,表单组件的拖拽、列表组件的数据列、Excel的列定义、或者更直接的数据表定义等,可以说都是在进行数据建模
  4. 大多数的平台都在弱化元数据的具体概念,将其分化到各个操作之中。
  5. 大多数的平台都留有一定的代码扩展性,例如表单代码块,组件生命周期,或者直接就是组件的扩展等,以应对过于复杂的业务逻辑
  6. 从某种程度上来说,留下的代码扩展点越少,代表其抽象程度越高,但是抽象程度越高可能配置的过程就会越繁琐( 语言级类型平台 ),甚至不必写代码的工作量小,因此需要在具体场景下去平衡抽象组件与代码扩展点。
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

我码玄黄

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值