企業級自定義表單引擎解決方案（二）——架構及核心子產品設計

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

概念還是有點多，有一些概念可能比較新，如果熟悉K2自定義表單，可能比較好了解一些。

　　對核心的一些功能子產品進行總體介紹如下(用.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的動态控件比較死闆，動态控件不能動态添加指令，還有其他很多限制，基本上斷了自定義表單的路了。

wike文檔位址：https://gitee.com/kuangqifu/sprite/wikis/pages

後端開源位址：https://gitee.com/kuangqifu/sprite

前端開源位址：https://gitee.com/kuangqifu/spritefronts

體驗位址：http://47.108.141.193:8031 （首次加載可能有點慢，用的阿裡雲最差的伺服器）

自定義表單文章位址：https://www.cnblogs.com/spritekuang/

流程引擎文章位址：https://www.cnblogs.com/spritekuang/category/834975.html （https://www.cnblogs.com/spritekuang/p/14970992.html ）