源寶導讀：天際移動平臺經過重構改版，近期正式發佈了1.0版本，我們在低代碼開發方面做了進一步增強。本文主要圍繞前端Model、前端業務邏輯(領域模型)、數據層與視圖層解耦(包裝器模式)3個方面，給大家分享一下統一數據層方案的設計思路和實現。
一、背景
天際移動平臺經過重構改版，近期正式發佈了1.0版。在低代碼開發方面進一步增強，內置了移動應用常用的系統組件，並提煉了表單和列表兩大核心數據容器組件，使用了統一數據層解決方案。
以移動應用常見的表單詳情頁面爲例，在移動平臺完成搭建到最終渲染，基本流程如下：
在平臺註冊獲取表單詳情數據的業務API，根據返回數據格式創建業務對象，業務對象包含業務字段。
拖拽表單容器到頁面中，綁定數據源到註冊的業務API。
拖拽表單組件，如文本框組件，綁定字段爲當前業務API返回業務對象的字段。
頁面渲染流程：
-
根據業務API返回的業務對象格式初始化前端Model。
表單容器調用領域服務獲取業務數據、填充Model、透傳表單組件。
表單組件根據綁定的業務字段動態解析Model數據進行渲染。
本文主要圍繞前端Model、前端業務邏輯(領域模型)、數據層與視圖層解耦(包裝器模式)3個方面，分享下統一數據層方案的設計思路和實現。
二、 前端Model
相較於後端Model，前端Model更像是一個容器，用於存放後端接口返回的數據，是前端數據層的最上游，也是接下來一切數據流動的起點。除了存儲接口返回的數據，一般前端維護一套Model還需要進行容錯處理，即運行時類型校驗，這對提高系統的健壯性有很大的幫助。
2.1、技術選型
我們選用了mobx-state-tree(MST)實現數據層的Model，它是一種狀態容器。MST的中心是活躍樹的概念。每個樹都具有形狀（類型信息）和狀態（數據）。從這棵活樹上，會自動生成不可變的，結構共享的快照。
類型的設計使得它在設計時和運行時都可以用來驗證類型正確性（設計時類型檢查僅在TypeScript中起作用）。
運行時類型錯誤：
設計時類型錯誤：
2.2、實現細節
根據數據容器組件綁定的業務API接口返回的業務對象元數據，動態生成該數據容器的前端model，並存儲到數據Store。
業務對象元數據示例：
動態生成前端model示例：
三、前端業務邏輯(領域模型)
在我們之前的《領域驅動設計DDD在前端應用的探索》分享中，詳細說明了如何利用DDD分層架構，來實現前端業務邏輯解耦的理論性探索，簡單回顧下。
3.1、前端業務邏輯解耦-DDD設計思路
3.2、實現細節
領域實體：
領域服務：
四、數據層與視圖層解耦(包裝器模式)
統一了數據層以後，組件只用來渲染數據，內部不用做數據相關的處理，更加輕量化。而數據層與組件渲染(視圖層)是通過包裝器模式進行解耦的。
在主流前端框架（React或Vue）中的高階組件HOC，就是採用這種設計模式，移動平臺是基於Vue技術棧開發的。
4.1、我們封裝了一個渲染被包裝組件的方法 renderWrappedComponent
4.2、創建數據容器包裝器dataContainerWrapper
created階段初始化數據Model存儲在數據Store。
mounted階段請求業務數據並填充到前端Model。
render階段將前端Model數據傳遞給實際的組件進行渲染。
包裝器與數據層數據是通過MobX進行關聯的，通過observer觀察數據變化，響應式更新包裝器。
4.3、在組件渲染時通過數據容器Connect，將組件與包裝器連接起來
五、總結
當前主流的前端框架在數據層上是缺失的，本次實踐結合前端Model、前端領域模型、數據層與視圖層解耦等方面，形成了一個可落地的解決方案，這也是一個趨勢，感興趣的可以深入瞭解下。
------ END ------
作者簡介
陳同學： 開發SM，目前負責天際移動平臺的相關研發工作。
也許您還想看
