一般來說，低代碼開發(fā)平臺從設計思想上可以分為“表單驅動”和“模型驅動”兩種。

前者將頁面形式和數據存儲結構合二為一，而后者類似于純代碼開發(fā)，實現(xiàn)了數據和性能的完全分離。那么兩者有什么區(qū)別呢？我來詳細解釋一下： 低代碼平臺中的“模型驅動”與“表單驅動”有何區(qū)別？

表單驅動

1、表單驅動是什么

表單驅動是傳統(tǒng)BPM的典型標志，也是使用Excel進行數據管理的常見做法：為了實現(xiàn)某個業(yè)務目標，利用計算機在多個人員之間自動傳遞文檔參與者根據某些預先確定的規(guī)則、信息或任務。一些由BPM或Excel服務器產品改造而來的低代碼開發(fā)平臺大多延續(xù)了這種表單驅動的模式。

簡單來說：如果不需要再配置數據庫實體，直接集成在表單中，也就不能對數據庫進行直接操作，稱為表單驅動。

2、表單驅動優(yōu)勢有哪些

表格驅動在軟件定制方面的優(yōu)點是：

(1)通用流程定制支持：通過流程過程中的抽象，充分考慮傳遞過程中的權限分配模型。一定程度上可以更加靈活地完成審批業(yè)務的定制。隱藏大部分轉賬業(yè)務。

（2）授權集成設計：根據業(yè)務特點，圍繞表單和流程，最大程度地集成授權模型，實現(xiàn)更細粒度的授權授權。

(3)表單可視化：在表單方面，系統(tǒng)最大限度地提取公共組件，并添加拖拽式設計，提取公共屬性供用戶選擇。同時可以在一些腳本動作中進行處理。一定程度上減少了代碼工作量。實現(xiàn)簡單的業(yè)務邏輯。

3、表單驅動問題與不足有哪些

表單驅動中，針對一些常見業(yè)務，提升了抽象和工具能力。但在實際應用中還存在很多問題。

(1)系統(tǒng)集成能力不足

在企業(yè)的實際應用中，獨立的業(yè)務審批服務很少。大多數情況下，組織需要從釘釘或企業(yè)微信中讀取，各種業(yè)務審批需要與相應的業(yè)務系統(tǒng)完成數據交互。即使是簡單的“請假流程”，也需要與企業(yè)微信、企業(yè)的HR（讀取員工剩余休假）系統(tǒng)、CRM等系統(tǒng)進行對接和交互，才能很好地完成業(yè)務流程。而這些系統(tǒng)接口和交互使得業(yè)務表單驅動模式很難輕量級運行。在系統(tǒng)集成的這些領域，過度依賴傳統(tǒng)編程。

(2)、無法處理復雜的數據關系

表單驅動模式，大部分表單都是從通用模板開始的，但通用模板中有更多不同的業(yè)務類型和樣式可供選擇。但在實際應用中，數據之間總會存在一定的數據聯(lián)動關系。特別是在一些專有領域，財務、人事、政務等審批的表單和流程的核心在于數據的流動，這些領域的模板略顯薄弱。但大多數模板在關系操作上過度依賴二次開發(fā)和實現(xiàn)。

(3)、開放性和交互能力較弱只能僅限于系統(tǒng)內部使用

表單驅動模型大多來自業(yè)務系統(tǒng)內部（企業(yè)OA、CRM），或者作為釘釘、企業(yè)微信等平臺的附屬部分。即使有業(yè)務整合，也大多僅限于內部業(yè)務系統(tǒng)整合?？缦到y(tǒng)或跨領域應用的成功案例很少。

(4)、部署復雜、維護困難

表單驅動本身的部署和維護并不困難，但業(yè)務真正集成后，會進行大量的業(yè)務和界面定制。這些定制導致大量混合代碼（模板和本機開發(fā)）。當業(yè)務發(fā)生變化或架構升級時，維護和開發(fā)將變得異常驚人。大多數系統(tǒng)在選擇技術升級或架構更改時都會放棄替代升級。這就是為什么很多成熟的行業(yè)軟件選擇避免流程引擎表單定制等間接的方便架構的應用甚至犧牲業(yè)務靈活性。

模型驅動

1、模型驅動是什么

模型驅動使用可視化建模技術來定義數據關系、處理邏輯并構建用戶界面，使開發(fā)人員和業(yè)務用戶無需代碼即可快速交付應用程序。模型驅動的系統(tǒng)運行時對于降低系統(tǒng)開發(fā)和維護的門檻，支持快速開發(fā)和運維具有重要價值。通常不需要專業(yè)的代碼工程師。業(yè)務專家和業(yè)務工程師無需關注技術細節(jié)，即可快速實現(xiàn)系統(tǒng)的定制化開發(fā)和運維。

簡單來說：如果需要創(chuàng)建一個數據庫實體與之映射，就叫模型驅動，以后可以直接操作數據庫。

2、模型驅動優(yōu)勢有哪些

（1）、系統(tǒng)架構更加清晰，表單和數據模型可獨立開發(fā)和維護；

（2）基于模型的API層，可以基于模型以少量的編碼實現(xiàn)更復雜的邏輯；

(3)純代碼開發(fā)的企業(yè)系統(tǒng)大多是模型驅動的架構。當需要與它們進行系統(tǒng)集成時，數據連接變得更加容易。有些低代碼開發(fā)平臺甚至可以直接連接其他系統(tǒng)的數據庫；

3、模型驅動的問題與不足有哪些

比形式驅動更難學。

基于表單區(qū)別和模型驅動區(qū)別

Gartner之前曾表示，低代碼服務提供商存在一定程度的業(yè)務重疊，但各有其邊界，其出發(fā)點和動機也不同。這些服務提供商的區(qū)別在于其技術框架和驅動程序的差異。

例如，針對專業(yè)開發(fā)人員或業(yè)務人員等各種角色的模型驅動的低代碼平臺，具有強大的本地化定制支持能力。平臺開發(fā)過程中需要與領域專家或企業(yè)IT共同協(xié)作，適合高層次、高水平的服務。中等IT成熟度企業(yè)、白代碼和低代碼等服務提供商。

從以上幾類的出發(fā)點和動機不難看出，雖然大家都在談論自己的低代碼能力，但他們解決的實際應用場景卻有很大差異。主要底層技術路徑主要是形式驅動和模型驅動。因此，無論怎么稱呼，還是要落入實際的應用場景中去解決。

很多時候，站在客戶的角度，我們從來不關心我們是誰，我們的產品基于什么架構，而客戶最關心的是誰能解決我的問題。例如，對于企業(yè)內部的協(xié)作OA、自動化管理等輕量級需求，可以使用表單驅動的低/無代碼平臺。如果涉及到企業(yè)的核心業(yè)務，比如銀行業(yè)估值減值、融資租賃、風控等企業(yè)級核心業(yè)務系統(tǒng)，主要依賴模型驅動的低代碼廠商。

但無論低代碼服務商主要是表單驅動還是模型驅動，本質上都是為企業(yè)數字化提供自動化解決方案，加速企業(yè)數字化轉型的進程。

之前我也體驗過幾個低碼平臺，發(fā)現(xiàn)一些優(yōu)質廠商（比如推來客低碼）采用的是“模型驅動”的理念。在平臺上，開發(fā)者可以單獨設計用于定義數據模型的數據表、用于用戶操作的頁面以及運行在服務器上并承載復雜業(yè)務邏輯的服務器端命令。

我們專注高端建站，小程序開發(fā)、軟件系統(tǒng)定制開發(fā)、BUG修復、物聯(lián)網開發(fā)、各類API接口對接開發(fā)等。十余年開發(fā)經驗，每一個項目承諾做到滿意為止，多一次對比，一定讓您多一份收獲！