低代码定义：
低代码是近几年比拟火的一种应用程序疾速开发方式，它能帮忙用户在开发软件的过程中大幅缩小手工编码量，并通过可视化组件减速应用程序的高效交付。（低代码的定义来自 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、活字格）为了满足企业级利用对业务场景复杂度以及对数据一致性的高要求，其采纳“模型驱动”的理念进行设计。开发者能够在该平台上，别离设计用于定义数据模型的数据表，供用户操作的页面，以及运行于服务器上、承载简单业务逻辑的服务端命令。
即使是没有受过业余编程训练的平民开发者也能轻松构建出专业级利用，达到满足数据库设计范式、表与页面分离式设计、前后端拆散架构等软件开发行业宽泛举荐的技术要求，为企业级利用的开发和保护打下松软的根底。