欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

—— 1. 魔力象限 ——

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

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

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

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

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

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

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

—— 3. 主要模塊 ——

1. 模型

2. 邏輯

3. 展現(xiàn)
   

4. 報表

5. 權(quán)限

6. 擴(kuò)展

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

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

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

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

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

—— 4. 兩種模式 ——

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

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

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

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

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

1. 模型

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

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

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

2. 展現(xiàn)

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

SF 頁面設(shè)計器

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

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

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

Outsystems 頁面設(shè)計器

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

3. 邏輯

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

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

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

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

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

Client Action 如下所示，類似一個方法，可以接收入?yún)ⅲ珱]有返回值。

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

4. 報表

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

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

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

5. 權(quán)限

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

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

6. 擴(kuò)展

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

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

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

7. 其他

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

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

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

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

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

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

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

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

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

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

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

來源：https://mp.weixin.qq.com/s/5XNo-U7SSoV9eg48BCufwg