低代码开发平台的方案类型总结
低代码开发平台这两年突然呈爆发状态，各类低代码厂商如雨后春笋般冒出。但究其根本，具体的形式都大同小异，基本可以总结为四类：表单类型、页面区块类型、表格(Excel)类型、类语言级类型。
以下对这几种类型进行大体描述，不涉及细节，如果疏漏，欢迎交流。
一、表单类型
表单类型是低代码开发平台最常见的一种形式。
表单的核心为表单编辑器，流程编辑器，部分低代码开发平台还有业务流编辑器（对数据的增删改流程进行后续操作），有的低代码开发平台业务编辑器与流程编辑器是一体的。
这类低代码开发平台由表单编辑器出发，根据表单组件的类型直接生成列表页，由其中的特殊组件（例如子表组件，关联数据组件）定义关联关系。
这类低代码开发平台的列表页面一般比较固定，基本上每一种页面类型都需要定向（用代码）扩展。
在数据模型有了之后，一般由一个可视化数据编排工具，例如ETL，进行数据的分析，生成图表。
图表展示页一般由一个可拖拽的布局器去引用生成的图表。
此类型一般用在一些比较简单的后台数据管理、分析等场景，缺少一些更多场景的灵活性。
二、页面区块类型
以页面为单元进行编排，直接从菜单出发，每新增一个菜单就是一个页面，所有的数据建模都来自于页面上存在的部分。
其核心为页面编辑器，组件列表，以及一个逻辑编排器。
页面编辑器中，由列表或者表单等形成数据建模，各个组件之间的逻辑关系，直接被解析为数据模型之间的关联。
页面上所有的部分都被解释为组件，可以自建数据模型，也可以引用其他的模型。
此类低代码开发平台，弱化数据建模（后端逻辑）的独立性，直接从菜单（或者路由）作为起点，一切的逻辑都收缩页面上存在。
只要页面上的组件（包括有一定业务属性的组件）足够地丰富，逻辑编排的方式足够地多，那么可覆盖的场景就越广。
此类型市面上也比较多，各类大屏编辑器也属于这一类型，其能力强依赖于其组件的丰富程度和逻辑编排能力的完整度。
三、表格（Excel）类型
直接以表格进行建模，利用Excel强大的函数公式能力。
这一类低代码开发平台在几年前比较常见，现在的流行度逐渐在降低了。
直接以一张Excel表作为数据模型，定义每一列是什么意思。
所有的表单、表格、流程等，都表现为一个Excel表。
需要扩充部分动态的公式，甚至数据表之间的影响公式。
权限、组织、人员、菜单等都放在外面，其数据也可以由Excel管理。
由于Excel的流行性，这类低代码开发平台的上手难度较低，尤其是对Excel比较熟悉的用户来说，只需要稍微学习一点新的公式和编排逻辑即可上手。
但是同样，由于这类平台过于依赖于Excel，想做更复杂业务的时候，需要用户对Excel的复杂功能和业务抽象逻辑都有极深地了解才能继续，无形中的学习成本实际上是极高的。
同时，由于对Excel的依赖性，也丧失了一部分页面上的灵活性。
这类低代码开发平台常用于一些本身业务就依赖于Excel，同时对单据还原度要求比较高的场景。
四、类语言级类型
这类低代码开发平台目前市场出现较少，严格来说已经快脱离低代码平台的范畴了。
这类开发平台将所有的操作都细化到一个最小单元，几乎与写代码等同，但是更强化可视化编排这个能力。
一般来说这类低代码开发平台比较像“古老“的VB语言，将所有的组件都拆分为 属性、行为、事件。
然后用一个可视化语法树的形式，允许你对各个组件的事件进行捕获，然后执行一些其他的行为。如数据处理等，也是一个组件，主要用于可视化编排逻辑使用。
对于后端的逻辑处理也类似，提供几个原生的系统能力组件，在可视化语法树中进行逻辑编排调用。
只要逻辑单元，系统能力单元，组件单元足够丰富，“理论上”可以做到代码能做的所有功能。(底层能力除外)
这类低代码开发平台一般会提供完整的入门方案，生态市场，扩展文档，调试流程、发布流程等，如一门语言一般。可以说是一个可视化写代码的方式。
上手难度较高，需要一定的编码逻辑基础才能上手，但是比较学一门语言的难度，还是要低一些的。
总结：
所有低代码开发平台都是在将代码过程分块后进行某个方向的抽象，并进行可视化逻辑编排，将最细节的那一部分代码留在组件或者逻辑块内部，因此，这四种类型也可以认为是四种逻辑抽象的方向。
而从目前来看，所有低代码开发平台都无法完全地解决所有的问题，其更像是一个同类业务模型的高级抽象，以便在短时间内解决更多类似的问题，甚至可以自动化地解决一些问题( 如果样本足够多，个人相信可以做到根据描述生成一部分的功能出来 )。
大多数的低代码开发平台都无法绕过元数据（数据建模）建立这一关，表单组件的拖拽、列表组件的数据列、Excel的列定义、或者更直接的数据表定义等，可以说都是在进行数据建模。
大多数的低代码开发平台都在弱化元数据的具体概念，将其分化到各个操作之中。
大多数的低代码开发平台都留有一定的代码扩展性，例如表单代码块，脚本，组件生命周期，或者直接就是组件的扩展等，以应对过于复杂的业务逻辑。
从某种程度上来说，留下的代码扩展点越少，代表其抽象程度越高，但是抽象程度越高可能配置的过程就会越繁琐，有些部分甚至不比写代码的工作量小，因此需要在具体场景下去平衡抽象组件与代码扩展点。
