前言：新冠疫情卷土重來給企業的生存和發展帶來新的挑戰，面對內部外市場環境的不確定因素，企業亟需保持業務的連續性，如何加快創新的速度，對抗不確定性帶來的風險，而低代碼無疑是最佳選項。本文將從實踐角度著筆，為大家詳細如何通過萬應低代碼復刻出一個新能源汽車電商平臺。

 

說明： 本文旨在展示、教學如何通過萬應低代碼，在短時間內快速開發電商官網，最終的復刻界面不作為商業使用。

 

 

萬應低代碼的通用實現過程

 

作為領先的一體化應用開發平臺，萬應低代碼憑借著模型驅動理念，在數字化項目的構建上能夠快速完成數據模型、業務模型、業務邏輯的定義，具備穩定強大的兼容和集成能力，一次設計即可多端適配。

 

 

萬應低代碼平臺能力結構圖

 

在具體項目的創建步驟上，萬應低代碼也能極大地簡化了傳統開發的流程，充分提高開發效率。

 

 

應用系統實現流程圖

 

接下來，我們以某新能源汽車品牌的電商平臺為例，根據訂購汽車業務場景進行低代碼實踐流程演示。

 

 

 

一、業務需求分析

 

基于汽車預定的業務需求，我們認為用戶進入賣車平臺后，需要能夠直觀查看到汽車信息（如：車型、版本、規格、產品圖片、價格等），且可根據規格的增配動態、靈活地調整價格。

 

 

 

 

 

用戶在選擇目標車型后，可進行用戶創建、加入購物車、預定、下單、協議簽署、支付等全流程操作，同時拆分定金與后續尾款，記錄用戶付費習慣。

 

 

 

 

二、定義業務實體

 

接下來，我們根據分析出的具體業務需求，整理出實現UE和隱藏邏輯所需的業務實體，明確多個業務模塊之間的關系與細節，完成業務實體、相關字典的屬性和內容定義。

 

并根據實際需要，在萬應低代碼預設的系統實體-用戶信息（User）中，拓展的用戶信息與實體。

 

 

 

用戶訂車相關業務實體構建參考

 

 

車型相關實體邏輯定義參考

 

 

三、設計主要業務邏輯與PaaS能力配置

 

通過分析，本電商平臺的后臺業務邏輯主要為預訂流程，包含創建用戶、創建訂單、創建付款記錄三個步驟，而大多用戶可能數年內只會購買一輛新能源汽車，因此在本例實踐中，我們傾向于將其解耦為多個可獨立操作的子流程形式，通過子流程調用的方式組合成大流程。

 

 

流程構建示例

 

 

1.構建賬戶子業務邏輯

 

首先根據賬戶子業務邏輯，在萬應低代碼平臺定義入參，主要包括：郵箱、賬戶、姓、名、賬戶類型、手機號碼等。

 

 

 

賬戶子業務邏輯入參定義

 

業務邏輯的出參，通常是由業務邏輯本身的能力和需要使用這個業務邏輯業務方定義的。對于創建賬戶來說，一般都會需要返回這個新創建的用戶ID。

 

 

 

賬戶子業務邏輯出參定義

 

在業務邏輯的編排階段，萬應低代碼能夠提供一目了然的可視化編排體驗，但在此之前，我們需要先分析業務邏輯，得出核心邏輯，異常情形，然后考慮輸入、輸出信息的處理。

 

以【創建賬戶】這個業務邏輯為例：

 

① 核心邏輯

 

向【系統實體-用戶信息】中插入一個賬戶，其包括姓、名、郵箱、手機號、密碼、賬戶類型等字段。

 

② 賬戶去重

【用戶信息】實體中已存在的相同數據（如：郵箱、手機號），應進行查詢去重處理。

 

③ 賬戶類型判斷

 

需要根據流程輸入參數判別企業賬戶和個人賬戶。

 

 

 

賬戶子業務邏輯編排

 

在數據源層面，我們需要明確數據的加載條數，按需加載，提高系統子性能；同時明確數據源的輸出字段，避免不必要的內存、CPU、寬帶消耗。

 

 

2.創建車輛訂單子業務邏輯

 

車輛訂單的子業務邏輯的出入參設定方式與前面大致類似。

 

 

 

賬戶子業務邏輯出參定義

 

 

 

賬戶子業務邏輯出參定義

 

但在邏輯編排時，我們可以利用循環節點把一段相同的流程，注入不同的參數和變量，以此簡化邏輯編排設計，本例中我們將用戶選擇的車輛規格信息，循環的插入到訂單規格表中，循環執行。

 

 

 

 

3.創建定金支付訂單子業務邏輯

 

用戶創建車輛預訂的訂單后，需要支付定金，并與后續付款/金融機構貸款（如有）構成完整的購車付款流程，于是我們需要為首筆定金創建訂單，以便后續追蹤。

 

 

 

入參定義

 

 

出參定義

 

在定義好出入參之后，邏輯編排時需要特別注意安全隱患的排查，例如在客戶端傳入的訂單總價或商品價格可能被用戶篡改，因此本例中，車輛的定金金額，直接從配置表中讀取，用戶無法輸入和修改。

 

 

 

同時應該合理利用異常處理節點，每條業務邏輯默認返回三個參數，拋出異常，能夠幫助用戶更好的定位錯誤，尤其是復雜邏輯編排，通過日志和異常信息就能快速定位到錯誤。另外前端用戶使用系統時，也能準確、清楚地知道錯誤原因。

 

 

 

4.創建支付二維碼子流程

 

下一步我們需要為平臺提供支付能力，那么如何使用萬應低代碼平臺的支付能力呢？在本例中通過連接器的調用微信支付和調用支付寶這兩個節點來實現。

 

調用支付能力需要遵循以下步驟：

• 在微信/支付寶平臺申請相應的支付能力和商戶號，獲取的商戶號和密鑰；

• 在萬應低代碼平臺設計后臺-密鑰管理中，引入微信支付相關的密鑰；

• 通過密鑰分組和密鑰鍵值兩個實體數據源，開發一個對密鑰實體管理的界面；

• 錄入獲取到的微信支付密鑰信息；

• 配置支付信息。

 

 

 

在業務邏輯中調用微信支付連接器：

 

 

 

5.支付成功訂閱流程

 

用戶通過微信掃碼完成支付后，將存儲付款的結果記錄于“支付訂單實體”實體。為實現該功能，我們需要設計一個業務邏輯，并配置其事件訂閱。出入參及邏輯編排就不過多贅述，大家可參考如下示例。

 

 

 

定義入參

 

 

邏輯編排

 

要注意的是在配置支付回調事件時，我們需要盡可能地保證傳參的一致性，并建議為實體定義索引，這樣能夠大幅提高查詢速度。

 

 

 

 

四、設計應用界面

 

1.頁面布局

 

在進行界面設計時，首先需要分析布局，明確頁面布局、彈窗及交互變化后的界面后，建立清晰的頁面容器框架，合理選擇容器，并將同一內容/同一業務顯隱性的元素歸置于同一容器內。

 

 

 

本例操作界面右側為固定寬度，不適合采用分欄容器進行布局，我們選擇兩個彈性容器進行布局。彈性容器的布局能力十分強大，其水平布局、垂直布局能夠讓組件分行、分列展示，還能提供響應式布局功能。

 

 

 

 

2.組件的應用

 

本例中我們還用到了列表組件。

 

 

 

作為萬應低代碼平臺最強大的組件之一，列表組件可支持數據源/數組對內容循環的、嵌套循環的渲染，可以對列表項或其子組件的邊框、背景等樣式，結合數據源當前行的表達式進行綁定，設計出復雜的選擇項控件。

 

 

 

①萬應低代碼所有組件的呈現（技術上叫做渲染），都是依賴數據綁定實現的。

比如列表組件根據10行數據渲染一個完整的列表，一個文字組件顯示一段文字，一個輪播容器輪播到某一項（本質上是指定變量對應的一項）。

 

②萬應低代碼平臺組件屬性綁定表達式時，都是響應式的。

表達式里任何一個子表達式（變量、數據源）改變時，都會自動、及時的反饋到組件的呈現上。表達式支持只讀，需通過動作可實現數據的修改。

 

③如果多個組件綁定一個相同數據，組件之間將產生聯動。

 

④變量驅動組件是支持雙向綁定的

如輪播容器改變輪播項綁定的變量、翻頁組件會改變當前頁碼、標簽控件會改變當前標簽的選擇項等。再如所有的表單組件，都會改變表單的值（本質也是一個變量）。這種現象就是雙向綁定。

 

 

 

3.選擇頁面數據源

 

數據源是萬應低代碼平臺貫穿后臺（或遠程）數據與前端界面的管道，本質上是前后端分離開發模式的重要基礎能力。

 

數據源分為實體數據源、業務邏輯數據源和大數據模型數據源。

 

 

①實體數據源

依賴后臺定義的實體模型及關聯關系，選擇數據源時，分類和展現的結構完全和實體建模部分完全一致。讓后臺的實體數據可以在前端界面呈現或實現修改、刪除。

 

 

②邏輯數據源

業務邏輯數據源能夠把我們在后臺業務邏輯模塊，定義的業務邏輯，輸出的數據（即出參）跟控件結合展現。

 

 

 

 

③大數據模型數據源

大數據模型數據源是一種專門用來做大數據分析的數據源，需要配合管理后臺大數據->數據模型模塊使用。

 

 

 

本例需要分析電商平臺中哪種顏色的車型賣的最好，并得出臺數和金額的折線圖，應該怎么做呢？

 

1）建立訂單車型顏色分析的數據模型，然后進入設計界面

 

• 車輛的銷量數據、金額和臺數，是記錄在訂單實體中，因此我們需要從左側實體中把訂單拖入到視圖，由于僅分析銷量，交付中心、付款信息等字段無需選擇。

 

• 最終客戶選擇何種規格，是存儲在訂單規格表中的，因此我們可以做一個內連接，拖入訂單規格表，建立內連接。

 

• 訂單規格表里冗余了一部分車輛規格的信息，但是并沒有存儲規格分類字段。因此我們還需要拖入車輛規格、車輛規格這兩個實體，根據關系字段建立左連接。

 

• 隨后點擊數據預覽，可以看到模型已經幫我們把模型平面化了，展示出了我們需要的數據。

 

 

 

2）在界面中使用大數據模型數據源

 

• 引入剛才創建的大數據模型；

 

 

 

• 由于我們后臺定義的大數據模型內包含車輛所有規格信息，但我們實際只需要分析顏色規格相關的銷量，因此我們需要給大數據模型加上查詢條件，加載數據源；

 

 

 

 

 

• 跟組件結合展示大數據模型，此處我們拖入一個折線圖控件，維度選擇所屬規格，第一Y軸選擇訂單總價，第二Y軸選擇對訂單總價做計數

 

 

 

 

 

預覽就能看到最終的折線圖效果：

 

 

 

4.使用頁面動作流

 

頁面動作流是萬應低代碼平臺打造前端界面邏輯，最強大的武器之一，頁面動作流是一種前端業務邏輯編排的方式，它有若干動作節點構成，目前有11大類，100余個動作節點，它負責處理、加工各種復雜的數據，負責協同前端控件之間的呈現，負責調用后臺和遠端業務邏輯，幾乎可以覆蓋任意前端邏輯。

 

目前是通過事件(前端術語叫做event)來觸發，每個組件都具備事件屬性，頁面本身也具有加載事件、加載完成事件和觸發器。

 

 

 

動作流使用步驟：

1.確定需觸發事件的目標組件；

2.創建動作流：考慮其功能，并定位到對應的節點；

3.排除異常情況：選擇合適的條件判斷和分支，優化動作流；

4.創建測試數據：測試動作流的邏輯是否正確。

 

通過事件觸發動作流時還需要注意以下幾點：

 

① 組件可配置一個或多個事件，事件可以觸發動作流的執行；

② 頁面分為頁面加載事件和頁面加載完成事件。頁面加載事件先于頁面加載完成事件執行，但是不能確保頁面加載事件里的動作流，在頁面加載完成事件開始執行時，都執行完畢；

③ 頁面事件中的觸發器支持周期性的觸發指定動作流。

 

 

 

5.使用無所不在的表達式

 

表達式是一種強大的、響應式的數據加工方式。

• 強大體現在前端頁面開發應用到的函數、表達式，支持通過可視化的方式實現。

• 響應式是指表達式中的任一變量、數據源，通過系統自動跟蹤，可自動響應至組件屬性。

 

表達式的用途有：

① 綁定組件屬性

② 構建數據源查詢條件

③ 綁定表達式節點的屬性

④ 綁定動作的屬性

 

五、項目的打包和發布

 

依照上面步驟，實現系統功能模塊的功能開發后，通過萬應低代碼平臺的打包發布功能，將應用發布到體驗環境完成集成測試，發布到正式環境投入使用。

 

萬應低代碼平臺官方提供集群運行環境：

由萬應官方提供完整的運維服務，客戶無需關心服務器、數據庫、對象存儲的運維工作，只需選擇一個環境的型號就能完全部署。

 

用戶自己提供云服務進行部署：

客戶提供至少兩臺4C8G的服務器，在根據文檔或在運維人員的指導下，初始化服務器的集群環境（本質上是初始化一個K8S+Docker的運行環境），將環境信息配置到萬應低代碼平臺。這種情況下客戶需要保證服務器的穩定性和安全。

 

 

具體步驟如下：

① 新建一個部署環境；

 

 

 

② 對項目進行打包，發布至體驗環境完成集成測試；測試完成后，即可發布至正式環境投入使用；

 

 

 

以上就是本期萬應實踐的全部內容，感謝大家的觀看，如果想要深入了解萬應低代碼和更多實踐案例，歡迎聯系我們，期待您的真知灼見！