低代码定义：

低代码是近几年比较火的一种应用程序快速开发方式，它能帮助用户在开发软件的过程中大幅减少手工编码量，并通过可视化组件加速应用程序的高效交付。（低代码的定义来自Forrester报告，被认为是低代码一词的起源）。

而这显然不是软件工程界第一次试图通过结合可视化开发技术（我们称之为“模型”）和代码自生成来减少手工编码。事实上，正如GradyBooch所说，软件工程的整个历史都是关于提高抽象层次的。低代码是减少开发应用程序所需手工编码量的最新尝试。而这也是我们从软件工程开始之初就一直追求的目标。

通常来讲，低代码开发平台在设计思想上可以分为“表单驱动”和“模型驱动”两种。前者将页面的表单和数据的存储结构合二为一，而后者则与纯代码开发类似，实现了数据与表现得完全分离。那么二者之间究竟有何区别呢？下面给大家详细讲解：低代码平台中的“模型驱动”与“表单驱动”有何区别？

​

一、表单驱动

1、表单驱动是什么？

表单驱动是传统BPM的典型标志，也是使用Excel做数据管理的常见做法：为了实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。一些从BPM或者Excel服务器类产品转型而来的低代码开发平台，大多延续了这种表单驱动的模式。

简单来说：如果不需要再配置数据库实体，直接集成在表单中，也就不能对数据库进行直接操作，称为表单驱动。

2、表单驱动优势有哪些？

表单驱动在软件定制方面的优势有：

（1）、通用流程定制支持：通过针对流程过程中的抽象充分考虑到了流转过程中的权限分配模型。在一定程度上可以更灵活地完成审批业务上的定制。瞒住大部分流转业务。

（2）、权限集成化设计：根据业务特点，以表单和流程为中心，最大程度地集成权限模型，实现更细粒度的权限授权。

（3）、表单可视化：在表单方面，系统最大程度地提取通用组件，增加拖拽设计抽取通用属性方便用户选择。同时在部分脚本动作中实现可以话处理。在一定程度上减少代码工作量。实现简单业务逻辑。

3、表单驱动问题与不足有哪些？

在表单驱动中，针对一些通用业务做了抽象和工具能力的提升。但在实际应用中还是存在了很多的问题。

（1）、系统集成能力不足

在企业实际应用中，很少有独立存在的业务审批业务，多数情况下，组织机构需要从钉钉、或企业微信读取、而各种业务审批则需要跟响应的业务系统完成数据交互。即使是简单的“请销假流程”也需要和企业微信、企业的HR（读取员工剩余假期）系统，CRM等系统进行接口交互，才能很好的完成业务流转。而这些系统接口交互使得业务表单驱动的模式很难以轻量级的模式来运行。而在这些系统集成领域则过度地依赖传统编程。

（2）、无法处理复杂数据关系

表单驱动模型，大多数表单起始于通用模板，但通用模板中更多可选择的不同业务种类以及风格样式。但实际应用中，数据间都会存在一定的数据勾稽关系。特别是一些专有领域类似于，财务、人事政府事务审批中其表单及流程的核心还是在于数据的流转，在这些领域模板就略显鸡肋。而大多数模板在勾稽关系运算方面过渡地依赖二次开发实现。

（3）、开放及交互能力较弱只能局限于内部系统使用

表单驱动模型，大多数主要还是来自于业务系统内部系统（企业OA,CRM），或者作为钉钉、企业微信等平台的附属部分即使有业务集成也绝大多数局限于内部自有业务系统集成。在跨系统或领域应用中鲜有成功的案例。

（4）、部署复杂维护困难

表单驱动本身部署及维护并不困难，但在真正融合业务后会进行大量的业务和接口定制。这些定制使得大量的混合代码（模板和原生开发）存在。在业务变更或者架构升级时，维护开发会出现超乎现象的复杂。多数系统在选择技术升级或架构改变时会抛弃替换性的升级。这也是很多成熟的行业软件即使牺牲业务的灵活度也要也选择避免流程引擎表单定制之类的应用存在已便于架构的间接性。

二、模型驱动

1、模型驱动是什么？

模型驱动使用可视化建模技术来定义数据关系、流程逻辑和构建用户界面，使开发人员和业务用户能够快速交付应用程序，而不需要代码。系统运行时模型驱动对于降低系统开发和维护门槛、支撑快速开发和运维具有重要价值。通常不需要专业的代码工程师。业务专家、业务工程师也不用关注技术细节就可以快速实现系统的定制开发和运维。

简单来说：如果需要再创建数据库实体与之映射的，称为模型驱动，后续可以对数据库进行直接的操作。

2、模型驱动优势有哪些？

（1）、系统架构更清晰，表单和数据模型均可单独开发与维护；

（2）、基于模型的API层，使用少量编码即可基于模型实现更多复杂逻辑；

（3）、纯代码开发的企业系统绝大多数都是模型驱动的架构，当需要与之做系统系统集成时，数据打通变得更加容易，部分低代码开发平台甚至能直连其他系统的数据库；

3、模型驱动的问题与不足有哪些？

上手难度比表单驱动高。

三、两者区别总结：

之前Gartner就曾表示过低代码服务商在一定程度上有业务上的重合，但各自也都有边界，出发点和动因也不尽相同。这些服务商的不同之处在于其技术框架与驱动的区别。

比如面向专业开发人员或业务人员等多种角色的模型驱动低代码平台，具有强大的本地化定制支持能力，在平台开发过程中需要与领域专家或者企业IT进行联合协作，适用于服务高级别和中等级别IT成熟度企业，具体服务商包括：活字格、织信Informat、ClickPaaS等。

以表单或办公自动化应用程序，提供轻量级解决方案以满足相应市场需求的无代码平台厂商（CADP），比如：钉钉宜搭、氚云、轻流等。

还包括像用友、金蝶等企业应用厂商（Enterprise Application ），此类厂商主要通过向LCAP提供打包业务功能和连接器来扩展产品，以支持不同范围的特定行业或特定领域的应用程序及解决方案。

此外，还有像阿里巴巴、百度、微软等云服务厂商（Cloud Service Provider ），这些大型云服务提供商寻求加强其云服务，以扩大销售，目标是通过基于各自云平台的解决方案，发展合作伙伴的生态系统。

从上述几种类型的出发点和动因其实不难看出，虽然大家都在谈论自己具备低代码能力，但解决的实际应用场景却有着千差万别。事实上，不论是LACP还是CADP或云厂商等包罗万象的标签，其实都是营销性词汇，其主要的底层技术路径主要还是表单驱动和模型驱动，因此它不管怎么称呼，还是要落到实际解决的应用场景。

很多时候，从客户视角来看从来都不关心我们是谁谁谁，我们的产品是基于什么架构，客户最关心的是谁能解决我的问题。比如像企业内部的协同OA、自动化管理等轻量级的需求，完全可以使用以表单驱动的低/无代码平台。如果涉及到企业核心业务，比如像银行业的估值减值、融资租赁、风控等企业级核心业务系统，主要依靠的还是以模型驱动为主的低代码厂商。

但不论是以表单驱动还是模型驱动为主的低代码服务商，本质上都是为企业数字化提供自动化解决方案，并加速企业数字化转型进程。

之前，我也曾体验过几家低代码平台，发现有一些比较优质的平台（如织信Informat、活字格）为了满足企业级应用对业务场景复杂度以及对数据一致性的高要求，其采用“模型驱动”的理念进行设计。开发者可以在该平台上，分别设计用于定义数据模型的数据表，供用户操作的页面，以及运行于服务器上、承载复杂业务逻辑的服务端命令。

即便是没有受过专业编程训练的平民开发者也能轻松构建出专业级应用，达到满足数据库设计范式、表与页面分离式设计、前后端分离架构等软件开发行业广泛推荐的技术要求，为企业级应用的开发和维护打下坚实的基础。