阿里云|低代码平台的各种方案总结( 二 )

这类平台比较少，严格来说已经快脱离低代码平台的范畴了
这类平台将所有的操作都细化到一个最小单元，几乎与写代码等同，但是更强化可视化编排这个能力
一般来说这类平台比较像“古老“的VB语言，将所有的组件都拆分为属性、行为、事件
然后用一个可视化语法树的形式，允许你对各个组件的事件进行捕获，然后执行一些其他的行为
数据处理等，也是一个组件，主要用于可视化编排逻辑使用
对于后端的逻辑处理也类似，提供几个原生的系统能力组件，在可视化语法树中进行逻辑编排调用
只要逻辑单元，系统能力单元，组件单元足够丰富， “理论上”可以做到代码能做的所有功能( 底层能力除外 )
这类平台一般会提供完整的入门方案，生态市场，扩展文档，调试流程、发布流程等，如一门语言一般
可以说是一个可视化写代码的方式
上手难度较高，需要一定的编码逻辑基础才能上手，但是比较学一门语言的难度，还是要低一些的
总结1. 所有平台都是在将代码过程分块后进行某个方向的抽象，并进行可视化逻辑编排，将最细节的那一部分代码留在组件或者逻辑块内部，因此，这四种类型也可以认为是四种逻辑抽象的方向。
2. 所有平台，都无法完全地解决所有的问题，其更像是一个同类业务模型的高级抽象，以便在短时间内解决更多类似的问题，甚至可以自动化地解决一些问题( 如果样本足够多，我相信可以做到根据描述生成一部分的功能出来 ) 。
3. 大多数的平台都无法绕过元数据（数据建模）建立这一关，表单组件的拖拽、列表组件的数据列、Excel的列定义、或者更直接的数据表定义等，可以说都是在进行数据建模
4. 大多数的平台都在弱化元数据的具体概念，将其分化到各个操作之中。
5. 大多数的平台都留有一定的代码扩展性，例如表单代码块，组件生命周期，或者直接就是组件的扩展等，以应对过于复杂的业务逻辑
6. 从某种程度上来说，留下的代码扩展点越少，代表其抽象程度越高，但是抽象程度越高可能配置的过程就会越繁琐( 语言级类型平台 ) ，甚至不必写代码的工作量小，因此需要在**具体场景**下去平衡抽象组件与代码扩展点。