超碰人人人人人,亚洲AV午夜福利精品一区二区,亚洲欧美综合区丁香五月1区,日韩欧美亚洲系列

—— 1. 魔力象限 ——

1. Mendix、Microsoft和 Outsystems 仍然保持在第一梯隊(duì)

2. Appian 有了很大進(jìn)步，排到了第四的位置

3. Salesforce 從第一象限掉到了第二象限

- Power Platform。微軟的平臺(tái)是一套產(chǎn)品的組合，包括 Power Apps、Power Automate 和 Power BI 等，這個(gè)使用時(shí)長(zhǎng)最短，他們產(chǎn)品的交互實(shí)在看不下去

比較遺憾的是只有 SF 是真正做過(guò)項(xiàng)目的，其他都只是學(xué)習(xí)研究過(guò)功能，所以有些項(xiàng)目層面的問(wèn)題可能會(huì)被忽略，比如部署、環(huán)境遷移、服務(wù)、價(jià)格等。

國(guó)內(nèi)產(chǎn)品深入使用或者研究過(guò)的包括：銷售易、云樞、明道云、簡(jiǎn)道云、網(wǎng)易數(shù)帆、宜搭、得帆等，其他還有一些更小眾的比如輕流、Air Table等。

企業(yè)級(jí)低代碼平臺(tái)面向的是企業(yè)用戶，雖然也有面向供應(yīng)商、合作伙伴、客戶等的 Portal，但更多的還是企業(yè)內(nèi)部員工，其目的也是解決企業(yè)日常運(yùn)營(yíng)管理中的問(wèn)題，相比面向 C 端用戶的產(chǎn)品，更看重?cái)?shù)據(jù)的準(zhǔn)確性、權(quán)限的精確性、邏輯的完備性、操作的便捷性，對(duì)樣式、交互、并發(fā)的要求更低一些。

—— 3. 主要模塊 ——

1. 模型

2. 邏輯

3. 展現(xiàn)
   

4. 報(bào)表

5. 權(quán)限

6. 擴(kuò)展

邏輯是低代碼平臺(tái)的核心，幾乎所有原先需要依靠代碼實(shí)現(xiàn)的功能都應(yīng)該可以通過(guò)邏輯流配置實(shí)現(xiàn)，Salesforce 的 Flow（包括原來(lái)的 workflow、Process Builder）、Outsystems 的 Client Action 和 Server Action、Mendix 的 Micro Flow 和 Nano Flow、Appian 的 Process Automation 等都是功能復(fù)雜而強(qiáng)大的邏輯流。向上，邏輯流對(duì)接前端組件，響應(yīng)頁(yè)面上的用戶操作，完成數(shù)據(jù)的校驗(yàn)、計(jì)算、賦值；向下，邏輯流對(duì)接模型，實(shí)現(xiàn)數(shù)據(jù)的增刪改查。

展現(xiàn)層是用戶交互的入口，常見(jiàn)的包括移動(dòng)端和 PC 端，頁(yè)面以列表頁(yè)和詳情頁(yè)為主。

報(bào)表是基于模型中的數(shù)據(jù)做報(bào)表展示，有些產(chǎn)品還區(qū)分了報(bào)表和儀表盤，但主要都是通過(guò)表格、透視表、圖表組件等對(duì)數(shù)據(jù)做匯總以及可視化呈現(xiàn)。

權(quán)限是對(duì)模型、邏輯、頁(yè)面、字段、報(bào)表以及行數(shù)據(jù)等的權(quán)限控制。

擴(kuò)展是在配置不能滿足需求的情況下前后端開(kāi)發(fā)擴(kuò)展的能力。

—— 4. 兩種模式 ——

不同產(chǎn)品在對(duì)上述概念的具體實(shí)現(xiàn)上還是走了不同的路，我覺(jué)得整體可以分為兩類：

一類是 Salesforce，一類是 Outsystems、Mendix、Appian等。前者有點(diǎn)類似 iOS，后者類似安卓。

國(guó)內(nèi)廠商基本也是照著這兩種模式在抄，或者也不叫抄，只能說(shuō)英雄所見(jiàn)略同。

以下就以 SF 和 Outsystems 為例做一些具體的比較說(shuō)明。

在大方向上，這兩種模式的產(chǎn)品都是以模型為基礎(chǔ)，先建模，構(gòu)建系統(tǒng)框架，然后再考慮業(yè)務(wù)邏輯和頁(yè)面呈現(xiàn)。

1. 模型

Salesforce 模式下，創(chuàng)建模型后系統(tǒng)會(huì)自動(dòng)生成對(duì)應(yīng)的列表頁(yè)和詳情頁(yè)。搭建一個(gè)最常用業(yè)務(wù)對(duì)象管理功能速度非?？?，對(duì)用戶的要求也很低。

但這種一氣呵成行云流水的操作帶來(lái)的弊端就是系統(tǒng)比較封閉，頁(yè)面組件無(wú)法做更多的自定義，用戶只能簡(jiǎn)單做一些前端字段的必填校驗(yàn)，雖然后來(lái)出了 Dynamic Form 的功能，可以實(shí)現(xiàn)簡(jiǎn)單的根據(jù)其他字段值控制某個(gè)字段的顯隱，但整體可配置性還是比較低。

對(duì)于常見(jiàn)的前端組件間數(shù)據(jù)聯(lián)動(dòng)的需求支持就不夠好，比如：當(dāng)用戶輸入 A 字段時(shí)，根據(jù)一定邏輯自動(dòng)生成 B 字段，并且 B 字段也支持修改這種需求就配置實(shí)現(xiàn)不了，而 Outsystems 可以簡(jiǎn)單通過(guò)組件的 OnChange 事件實(shí)現(xiàn)。

2. 展現(xiàn)

- 詳情頁(yè)的字段、相關(guān)模型、活動(dòng)等

SF 頁(yè)面設(shè)計(jì)器

SF 數(shù)據(jù)列表頁(yè)

Outsystems 則提供了幾十個(gè)前端原子組件，從基本的 Form 相關(guān)的輸入組件、表格/列表類顯示組件、按鈕、布局到圖表類組件。這些組件由數(shù)據(jù)驅(qū)動(dòng)，比如輸入組件需要綁定變量，當(dāng)變量發(fā)生變化時(shí)會(huì)觸發(fā)頁(yè)面重新渲染，和 React 邏輯差不多。

雖然可以基于模型快速生成列表頁(yè)和詳情頁(yè)，但生成的頁(yè)面和功能也是比較簡(jiǎn)陋的，不能說(shuō)沒(méi)用，只能說(shuō)沒(méi)啥用，所以基本處于白手起家的狀態(tài)，觀感上比江蘇還要散裝。

Outsystems 頁(yè)面設(shè)計(jì)器

每個(gè)組件都可以單獨(dú)設(shè)置樣式，樣式可以用類（class）、行內(nèi)樣式或者直接寫(xiě) CSS 代碼，因此比較容易實(shí)現(xiàn)個(gè)性化的頁(yè)面，下圖是組件的樣式配置面板。

3. 邏輯

SF 現(xiàn)在主推的邏輯流是 Flow，流程節(jié)點(diǎn)包括：流程控制（分支、循環(huán)）、數(shù)據(jù)處理（增刪改查、數(shù)組處理）以及平臺(tái)封裝的動(dòng)作（發(fā)郵件）等。

SF 主要是通過(guò)數(shù)據(jù)的增刪改操作觸發(fā)Flow，不開(kāi)發(fā)的情況下無(wú)法實(shí)現(xiàn)通過(guò)單個(gè)前端組件的事件觸發(fā)。

SF Flow 部分節(jié)點(diǎn)

Outsystems 則是通過(guò)頁(yè)面組件的事件觸發(fā)前端邏輯流 Client Action，比如上面 Outsystems 設(shè)計(jì)器的截圖中，按鈕就是通過(guò) On Click 事件觸發(fā)名為 ButtonOnClick 的 Client Action。

不同組件支持不同事件，比如輸入組件支持 On Change、On Focus、On Blur 等事件，其實(shí)就和寫(xiě)前端 JS 代碼差不多了。

Client Action 如下所示，類似一個(gè)方法，可以接收入?yún)?，但沒(méi)有返回值。

這種模式基本就是把開(kāi)發(fā)轉(zhuǎn)成可視化配置，通過(guò)前端組件、前端邏輯流、后端邏輯流、數(shù)據(jù)模型實(shí)現(xiàn)了開(kāi)發(fā)效果。

4. 報(bào)表

Outsystems 比較粗糙，完全依賴用戶在屬性面板中的配置，和使用 ECharts配置屬性幾乎如出一轍。

讓用戶通過(guò)流程組裝出圖表需要的多個(gè)特定類型的參數(shù)，就實(shí)現(xiàn)這么一個(gè)平平無(wú)奇的報(bào)表，想想都覺(jué)得酸爽。

SF 則是可以基于模型搭建報(bào)表，再基于報(bào)表搭建儀表盤，配置過(guò)程比較流暢，實(shí)現(xiàn)效果也不錯(cuò)。

5. 權(quán)限

由于 Outsystems 這種模式比較散亂，頁(yè)面上的字段可能有各種來(lái)源，因此權(quán)限的配置也比較亂，不夠直觀，并且難以做到針對(duì)不同用戶做到行權(quán)限、列權(quán)限的控制。

SF 則由于強(qiáng)管控可以通過(guò) Profile、Permission 等實(shí)現(xiàn)非常精細(xì)的權(quán)限控制。

6. 擴(kuò)展

SF 的擴(kuò)展分為前端和后端，前端現(xiàn)在主推 Lightning Web Component（LWC），個(gè)人覺(jué)得開(kāi)發(fā)門檻比較高，需要對(duì)他的這一套框架有非常深入的了解才行，官方提供了 VC Code 插件，開(kāi)發(fā)完成后可以將組件同步到租戶內(nèi)。

后端則是提供了類 Java 的 Apex 語(yǔ)言，屏蔽了 Java 的一些底層技術(shù)細(xì)節(jié)，并且融合了類似 SQL 的 SOQL（Salesforce Object Query Language），能非常輕松地實(shí)現(xiàn)業(yè)務(wù)邏輯處理以及對(duì)數(shù)據(jù)庫(kù)的操作，非常易用。同樣地，由于 Apex 是個(gè) DSL，有一定的學(xué)習(xí)成本，并且由于 SF 的多租架構(gòu)，對(duì)數(shù)據(jù)庫(kù)的操作也有不少限制，需要開(kāi)發(fā)者格外注意。

Outsystems 在提供和消費(fèi)接口上可以簡(jiǎn)單配置實(shí)現(xiàn)，但開(kāi)發(fā)功能還沒(méi)實(shí)際用過(guò)。

7. 其他

還有一點(diǎn)國(guó)外可能相關(guān)沒(méi)那么關(guān)注，但國(guó)內(nèi)企業(yè)比較關(guān)注的是審批流。

Outsystems  不存在開(kāi)箱即用的審批流，雖然應(yīng)用市場(chǎng)中有相關(guān)的組件，但功能非常難用，上手成本很高，幾乎滿足不了國(guó)內(nèi)任何一家企業(yè)的需求，難以想象他們的售前該怎么給用戶解釋。

SF 則有自帶的審批流 Approval Process，雖然配置體驗(yàn)比國(guó)內(nèi)專門做流程的產(chǎn)品差不少，但已經(jīng)可以滿足常規(guī)的審批需求了，而且他還提供了完善的 API，客戶如有定制化需求可以基于 API 自行開(kāi)發(fā)審批功能，相當(dāng)于提供了一個(gè)小型的流程引擎。

—— 5. 總結(jié) ——

最后簡(jiǎn)單總結(jié)下：

SF 這類產(chǎn)品自成一體，提供了豐富實(shí)用的內(nèi)置功能，能快速搭建應(yīng)用；由于是強(qiáng)管控類產(chǎn)品，所以前端組件、樣式、交互難以定制化，只能通過(guò)開(kāi)發(fā)前端自定義組件實(shí)現(xiàn)，這需要專業(yè)的、深入了解其框架的前端開(kāi)發(fā)人員介入，門檻比較高。

Outsystems 這類產(chǎn)品的目標(biāo)用戶更偏開(kāi)發(fā)人員，容易配置出相對(duì)復(fù)雜結(jié)構(gòu)、交互或樣式的前端頁(yè)面，能滿足對(duì)交互有強(qiáng)需求的場(chǎng)景。

同時(shí)其缺點(diǎn)也很明顯：入門門檻高，需要了解前端組件、客戶端代碼、服務(wù)端代碼、SQL 等，缺乏開(kāi)箱即用的功能（是的，他也提供了很多模板，但事實(shí)上如果對(duì)產(chǎn)品架構(gòu)和模板細(xì)節(jié)不熟，改模板的時(shí)間還不如重新搭一個(gè)）；

缺乏最基本的列表頁(yè)篩選、排序、導(dǎo)出導(dǎo)入，以及數(shù)據(jù)權(quán)限、審批流程等，連最基本的增刪改查都要一個(gè)個(gè)手動(dòng)配置，搭建成本非常高，即使實(shí)現(xiàn)效果也很一般。

另外雖然做到了可視化，但系統(tǒng)中會(huì)充斥著大量組件、事件、流程、變量，后續(xù)維護(hù)成本非常高。

最后的最后，歸根結(jié)底，在軟件領(lǐng)域沒(méi)有銀彈，這兩類產(chǎn)品都滿足了一定的用戶需求，適用于特定的用戶場(chǎng)景，就看用戶關(guān)注的重點(diǎn)是什么了。

來(lái)源：https://mp.weixin.qq.com/s/5XNo-U7SSoV9eg48BCufwg