前言
我将低代码平台底层分为三种：流程引擎驱动、元数据对象(模型)驱动和视图驱动，不同类型平台具有各自的特点。
- 流程引擎驱动：以流程驱动视图。创建视图的时候，需要配置数据流程，比如提交、审批等节点，视图展示的是流程对象，因此视图自带业务功能按钮。典型的产品如轻流。
- 元数据对象驱动：元数据对象也即数据模型。创建视图的过程，就是创建对象的过程，对象对应的是视图中的列表和表单。对象本身并无业务功能，只有增删改查。因此视图也不具备业务功能按钮，但可以配置工作流以实现业务逻辑。典型的产品有明道云。
- 视图驱动：基于一个复杂的网页编辑器（并非表单编辑器）拖拉拽丰富的组件+数据设置而搭建的视图。典型的产品如微搭、宜搭
当然成熟的商业化产品可能包含多种特性，比如微搭也有元数据对象管理，明道云也有自定义视图的能力，但不同产品侧重不一样。
流程引擎驱动型低代码平台特点
截图源自轻流
流程的核心是流程表单，流程的查看、发起、提交、审核、结束/终止都离开不了表单。
这类低代码产品，页面创建一定是从流程表单创建开始的。创建表单的时候，添加编辑控件的过程，其实就是在给这个流程赋予业务字段。创建完表单自然而然需要配置表单提交的流程，比如指定审批阶段和审批人。
完成表单和流程的创建，列表视图也就出来了，列表字段即表单中的字段，列表页签就是流程的状态，列表上的按钮，就是流程操作按钮。
优点
流程表单样式、布局、字段基本固定，流程动作固定，列表字段基本固定，权限内置，因此这种低代码平台可视化配置交互流畅，配置量少，上手成本极低。对某些特定场景，比如考勤、人事登记等，可以做成模板直接提供给业务人员，理想情况下业务人员能够开箱即用，对没有开发能力的使用者非常友好。
缺点
缺点也非常明显：
- 每个页面都是一个流程，这个前提就是业务需求可以抽象为一个流程，但事实上并非如此。大多数业务只是普通的增删改查，数据的修改更适用角色权限控制，而非流程审批。
- 即使是业务需求可以抽象为流程，但复杂场景下业务数据可能处在多流程中，比如银行卡的挂失场景，可以划分为申请——受理——交付——完结，但受理环节又可以分为发起——审批——制卡——运输——入库——出库，这其中还可能有更多的细支流程，要将多个流程中的数据挑选出不同的字段展示给不同的操作人，一般的流程引擎很难实现。
- 当业务对象存在对一、对多关系时，流程实例和流程视图难以体现这种关系。
- 几乎没有自定义按钮的能力：既然已经设定了流程，那么所有的操作都属于流程操作，基于这个前提，自然也不会有自定义按钮的场景 （然而实践中有大量的场景需求自定义按钮逻辑。）
总之，基于流程引擎的平台，使用难度低，配置少，无法处理复杂场景。
视图驱动型的低代码平台特点
截图源自腾讯微搭
这类平台一定类似截图中的复杂的视图编辑器，不同于表单编辑器，视图编辑器有极其丰富的组件，每个组件都有丰富的配置项，组件之间的交互也可以通过设置流程+变量操作组装，几乎可以满足所有的视图需求。
缺点
简单来说，这种类型的低代码开发成本极高，上手难度极高，理论上可以满足最多最复杂的需求场景，但因为精力分散，最终的结果反而是只能满足大量简单的需求场景。
造成这个问题的根源是，视图视图控件和数据缺乏联系。
比如一个简单的查询列表，要完全自己配置，需要考虑数据源，字段，查询参数，返回结构，分页，更不用说配置上增删改查按钮。因此一般平台都提供一个数据源的功能，将列表与数据绑定，以减少配置压力。
此外，视图控件各种专业的配置项，能劝退多数开发者，能驾驭视图编辑器的人，往往都是有一定前端开发能力的人。
这类产品除了配置难度大，配置效率也很低。 控件、数据源、字段、变量，以及各种交互细节都需要考虑，本质上是换一种形式组织代码逻辑。
元数据对象驱动型低代码平台特点
截图来自明道云
这类产品的核心是元数据建模。目前市场上该类型的产品，创建视图大多数是从表单创建开始，但表单创建的本质，其实也是元数据对象的创建。
这类产品通常都有一个这么一个认知：元数据对象本身可以在很大程度上定义视图。比如字段的类型和编辑控件往往存在固定关系，对象自带的增删改查功能对应了视图的按钮；对象间的关系，比如对一，对多，也可以通过视图字段控件的对象下拉框、子表格等形式表示。
元数据驱动的视图，往往是固定的列表/表单视图，虽然无法实现灵活的自定义视图布局，但简单高效。 普通的业务人员能通过表单表单建模，快速得到列表和表单视图，实现增删改查功能。
缺点
这类产品的第一大问题是：元数据本身无法体现提交/审批这种业务类型操作属性，因此自定义按钮+自定义表单+流程设计器是必须的。
然而流程设计器的出现，必定会引入变量、逻辑网关、表达式等概念，增加了平台的使用难度。
此外除了流程设计器中的变量等概念外，对象和关系的理解也是有门槛的。
我们看到的这类产品，通常都是从表单开始创建视图，而很少有从对象建模开始。因为绝大多数人都无法将对象、字段、关系这些概念映射到视图上。比如用户在表单中拖一个客户单选下拉框，那就是建立对客户的对一关系，用户拖一个客户表格，那就是建立对客户的对多关系。这种设计可以在很大程度上减少用户的心智负担。
这类产品的第二大问题是，对象不能完全描述视图。
虽然一切数据操作需求都可以通过元数据和元数据之间的关系、行为来描述，但视图需求真不是元数据能够完全描述的了。比如说要自定义新增、修改、详情的表单布局和内容，要控制列/表单控件顺序、名称、样式、悬浮提示、条件展示、编辑联动，各种无法的导入导出需求等等，这些复杂需求意味着需要强大灵活的视图编辑能力。
总结
| 类型 | 覆盖场景 | 配置难度 | 视图能力 | 平台复杂度 | 平台建设核心 | 使用能力要求 |
|---|---|---|---|---|---|---|
| 流程驱动型 | 少 | 低 | 弱 | 低 | 流程引擎和数据报表 | 无 |
| 视图驱动型 | 多 | 极高 | 强 | 高 | 可视化视图编辑器和建模 | 开发级 |
| 模型驱动型 | 较多 | 较高 | 较强 | 高 | 元数据、工作流、表单编辑器 | 运维级 |
