狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

—— 1. 魔力象限 ——

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

2. Appian 有了很大進步，排到了第四的位置

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

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

比較遺憾的是只有 SF 是真正做過項目的，其他都只是學習研究過功能，所以有些項目層面的問題可能會被忽略，比如部署、環境遷移、服務、價格等。

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

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

—— 3. 主要模塊 ——

1. 模型

2. 邏輯

3. 展現
   

4. 報表

5. 權限

6. 擴展

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

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

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

權限是對模型、邏輯、頁面、字段、報表以及行數據等的權限控制。

擴展是在配置不能滿足需求的情況下前后端開發擴展的能力。

—— 4. 兩種模式 ——

不同產品在對上述概念的具體實現上還是走了不同的路，我覺得整體可以分為兩類：

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

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

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

在大方向上，這兩種模式的產品都是以模型為基礎，先建模，構建系統框架，然后再考慮業務邏輯和頁面呈現。

1. 模型

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

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

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

2. 展現

- 詳情頁的字段、相關模型、活動等

SF 頁面設計器

SF 數據列表頁

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

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

Outsystems 頁面設計器

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

3. 邏輯

SF 現在主推的邏輯流是 Flow，流程節點包括：流程控制（分支、循環）、數據處理（增刪改查、數組處理）以及平臺封裝的動作（發郵件）等。

SF 主要是通過數據的增刪改操作觸發Flow，不開發的情況下無法實現通過單個前端組件的事件觸發。

SF Flow 部分節點

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

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

Client Action 如下所示，類似一個方法，可以接收入參，但沒有返回值。

這種模式基本就是把開發轉成可視化配置，通過前端組件、前端邏輯流、后端邏輯流、數據模型實現了開發效果。

4. 報表

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

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

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

5. 權限

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

SF 則由于強管控可以通過 Profile、Permission 等實現非常精細的權限控制。

6. 擴展

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

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

Outsystems 在提供和消費接口上可以簡單配置實現，但開發功能還沒實際用過。

7. 其他

還有一點國外可能相關沒那么關注，但國內企業比較關注的是審批流。

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

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

—— 5. 總結 ——

最后簡單總結下：

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

Outsystems 這類產品的目標用戶更偏開發人員，容易配置出相對復雜結構、交互或樣式的前端頁面，能滿足對交互有強需求的場景。

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

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

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

最后的最后，歸根結底，在軟件領域沒有銀彈，這兩類產品都滿足了一定的用戶需求，適用于特定的用戶場景，就看用戶關注的重點是什么了。

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