先總體介紹一下大概的架構和核心模塊設計。先上一張整體設計圖

　　概念還是有點多，有一些概念可能比較新，如果熟悉K2自定義表單，可能比較好理解一些。代碼地址：https://gitee.com/kuangqifu/sprite，或者QQ交流：523477776

　　對核心的一些功能模塊進行總體介紹如下(用.net core實現，其他語言整體設計思路相差不大)

基礎設施：

自定義表單主要涉及到數據存儲，包括表單定義信息和真實的業務表存儲管理，可支持不同的數據庫存儲，Redis主要用在緩存更新通知上，Redis不存儲表單定義緩存

基礎組件：

表單基礎框架，.net core實現，用Dapper做ORM存儲，封裝了UnitOfWork，另外還包括了模塊管理、租戶/應用管理等基礎功能，不包括權限相關功能。

表單定義本地緩存：

表單定義信息對于自定義表單來說，訪問特別的頻繁，真實業務變更極少，需要不少的過濾查詢，如果存儲到Redis，涉及到頻繁的訪問以及數據過濾，對整體性能影響也比較大，所以這里考慮把表單定義信息存儲到每一個應用程序內存中，直接從內存中訪問表單定義信息，表單定義信息改變時，通知所有應用表單定義對應的數據已經更新，應用程序讀取數據時，會從數據庫讀取最新的數據存儲到內存中。表單定義信息還會存儲到瀏覽器Indexdb中，一條總的原則就是訪問自定義表單定義信息一定要快，就近獲取。

基礎數據本地緩存：

數據字典(用戶信息)也可以存儲到本地緩存，管理方式同表單定義本地緩存，數據字典變更極少，訪問大；業務表往往只存儲用戶Id，展示需要用戶名稱，所以也存儲到本地緩存中。

緩存變更通知：

修改了表單定義信息或者數據字典等，通過Redis通知所有應用程序清空本地緩存，再次讀取數據時，應用程序從數據庫或者接口讀取數據再填充到內存中。如果檢測到Redis斷開連接，則直接從數據庫或者接口讀取數據，待Redis恢復，再從內存讀取數據。Redis可由其他有發布訂閱中間件服務替換。

CurrentUser：

只提供接口定義，對接具體的框架實現具體的邏輯，比如框架使用Abp框架，則從Abp的ICurrentUser讀取用戶當前用戶信息。

微服務調用組件：

暫時未遷移，見作者其他博客描述。

租戶/應用配置管理：

對自定義表單數據在租戶和應用級別進行隔離，以支持Saas服務。

Sprite Comon：

自定義表單公共組件/模塊

動態Sql：

自定義表單比較核心的內容之一，所有對業務表的常規CRUD，都是通過動態拼接Sql語句完成以及動態參數，這里面涉及到大量的JObject操作，也就是開發者用得比較多的Newtonsoft.Json組件部分內容。

動態查詢條件：

對Sql的參數查詢，查詢條件定義為一棵查詢樹，然后根據樹完成Sql查詢條件Where子句的字符串拼接。

動態表達式：

也是一棵樹，每一個節點為一種函數或者取值，比如邏輯表達式、日期轉換函數、從方法獲取值、固定值等，根據根節點類型返回對應動態值

表單規則：

自定義表單靈魂所在，有了表單規則定義，才能稱之為表單引擎，可定義視圖或者表單規則；

表單規則事件：

比如用戶列表視圖新增按鈕點擊事件，部門樹用戶列表表單部門樹視圖樹節點選中節點變化事件，用戶列表視圖彈出對話框保存事件等，可以是視圖/表單本身或者控件觸發，也可以是子表單/子視圖本身或者控件觸發

表單規則執行：

當某一個規則定義的事件被觸發，可定義執行一系列執行動作，比如"用戶列表視圖新增按鈕點擊事件"觸發時，定義執行設置用戶列表選中部門參數、獲取用戶列表查詢參數定義、執行后端獲取用戶分頁數據方法、將執行結果傳遞給用戶列表等一系列動作。再比如"用戶列表視圖彈出對話框保存事件"事件觸發,驗證用戶Item視圖、驗證通過

定義時和運行時驗證：

自定義表單不需要寫代碼，則驗證就顯得非常的重要了，定義時各個模型之前數據是否正確，規則定義是否正確，運行時參數等是否正確等

序列化：

表單定義存儲往往是結構化的數據，很多定義信息可能以字符串的方式存儲，但JS前端往往需要Json數據，則需要進行序列化與反序列化操作。

Sprite Object：

自定義表單對象管理，包括對象、屬性、方法

Object管理：

Object管理與業務表需要完全同步，添加Object時，需要動態生成業務表的創建Sql語句，并在業務庫中創建具體業務表，業務表名稱與Object的Name字段對應，動態Sql是根據Object定義信息拼接Sql語句并在真實業務庫中執行Sql語句。

Property管理：

Object定義表，Property定義字段，自定義表單定義一些審計相關的字段并進行維護，包括Creator,CreationTime,IsDeleted等

Method管理:

定義方法，可以是執行Sql語句、調用微服務、反射調用，并包括方法能夠成功執行的附加信息定義，并對執行參數進行驗證，對業務表常規的操作已經定義到了自定義表單中，比如Create,Update,Get,List,PageList,TreeList等，不需要格外定義方法

業務表管理：

對Object和Property的管理，同步更新業務表表結構，他們之間需要完全的對應。

Sprite View and Form:

視圖管理：

自定義表單最小功能單元定義，比如用戶Item，用戶列表視圖，部門樹視圖等，抽離出Item視圖、列表視圖、樹視圖等各個單元視圖。

表單管理：

自定義表單視圖容器，表單不處理任何具體業務，只是將各種視圖聚合起來統一管理，可以對視圖進行布局，可以定義規則在視圖與視圖之間傳遞數據等。

視圖/表單控件：

統一定義不同視圖/表單固定區域的控件，比如列表視圖查詢區域控件，列表功能控件，新增，刷新，批量刪除等，或者列表行控件等，再或者表單流程相關控制按鈕

視圖/表單Wrap管理：

視圖或者表單只定義自身需要的功能，但用到哪些地方自身是不知道的，比如用戶Item視圖放入用戶列表彈出框中，部門樹表單用Card布局等

視圖/表單行列管理：

按照Grid布局，定義常規的行列布局管理

子視圖/子表單：

表單列或者視圖列的內容可以是子表單或者子視圖，運行時當發現是子視圖或者子表單，則動態再加載配置的視圖或者表單。

視圖/表單版本管理：

視圖或者表單本身或者任何關聯數據改變，都會重新生成版本號，并通知所有應用對應緩存變更并刪除應用本地緩存，瀏覽器每請求一個頁面，發現視圖或者表單版本號改變了也會更新瀏覽器本地存儲數據。

視圖/表單規則管理：

視圖和表單都可以定義自身規則，規則見上文描述。

宿主框架：

計劃將自定義表單宿主到Abp Vnext框架中，Abp框架負責登錄認證，用戶角色管理，菜單操作權限管理等，自定義表單公開Api供使用端調用，當然，使用其他框架做為宿主也是一樣的。另外，工作流引擎這塊，之前是用WWF研發的一套產品，但是微軟沒有計劃將其遷移到.net core，基本就宣告了死刑，所以之前的文章也就停止了；流程引擎這塊后續是會重新編寫，流程引擎+表單引擎，這塊自定義表單最終的形態，不過不都是后話了，自定義表單完全可以獨立存在。

前端(個人是做后端的，前端水平有限)：

　　前端的復雜程度不亞于后端，很多東西是需要配合后端一起定義的，前端+后端，才能形成一個整體。

　　前端可以是不同的架構，不同的應用，可以是瀏覽器，winform等，都是調用Api，這里選擇的是瀏覽器，技術選擇的是vue，框架選擇的是and design for vue

Ant Design for Vue:

使用此框架，可替換其他框架，但各個控件需要做相應的修改。

視圖：

定義視圖Layout、Item、列表、Tree等視圖。

表單：

定義普通表單、Div表單等

Wrap管理：

對視圖或表單進行包裝，包括Div、對話框、Card布局等各種包裝。

視圖/表單控件：

對前端各種控件進行二次封裝，注入規則，允許觸發事件和執行規則。

瀏覽器數據緩存：

比較核心的內容，自定義表單內容設計變更，需要即使的通知前端，同是自定義表單定義信息訪問又必須快速，不能有明顯的性能損失。IndexedDb存儲視圖/表單定義等信息，每次打開一個頁面時，遍歷所有關聯的視圖和表單Id和版本信息，與后端緩存數據進行比較，不同則更新本地緩存。

表單規則注冊與執行：

前端靈魂所在，視圖、表單、控件在創建的時候，都會注入規則，用戶進行某個操作時，如果有對應的事件定義，則找到規則定義，進而找到一系列視圖/表單/空間執行一系列規定。

動態表達式：

為一棵樹，同后端動態表達式比較類似。

自定義功能：

自定義表單也不可能抽象出所有的數據模型，特殊的業務可編寫代碼，完全自定義功能實現。后端一些報表或者某些業務模塊，開發人員自己寫業務邏輯，通過微服務或者反射配置方法，執行具體的自定義功能。前端則可編寫不同的自定義控件，并注冊到Vue框架中，自定義表單在某個功能上配置自定義控件名稱即可。

　　前端技術選型不要選擇angular，angular的動態控件比較死板，動態控件不能動態添加指令，還有其他很多限制，基本上斷了自定義表單的路了。

總結

以上是生活随笔為你收集整理的企业级自定义表单引擎解决方案（二）--架构及核心模块设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。