嘍哈嘍，大家好。

今天和大家分享一下，在vue中，如果高效的開發表單。

首先我們來確定表單的功能，表單主要是用來收集用戶數據的信息，然后提交后臺。也就是需要在頁面上提供一些列的輸入框，用戶完成輸入后，通過提交按鈕，觸發表單驗證，驗證不通過則提示錯誤，驗證通過則將收集的信息發送給后臺，后臺處理完成后，提示前端成功還是失敗。按照業務功能來說，表單分為新建和編輯兩種，其中數據驗證，提交的邏輯都是一樣的，只是編輯的場合，事先需要根據記錄的ID加載待編輯的數據 來填充表單。然后 編輯的提交 通常 是增量修改，就是只提交變化的部分。

以往我們開發表單，需要完成以下幾個步驟。

1. 構建layout，就是準備各種輸入框，備選項（單選按鈕、復選按鈕、下拉列表），確定報錯消息展示的位置。

2. 表單驗證

3. 表單數據提交，提交之前可能需要對待提交的數據做一下處理，以滿足接口要求。

在vue環境中，大家可能首先會想到用element-ui，因為它美化了輸入組件，定義來標準form的開發模式，提供了表單驗證的功能，使用element-ui可以幫大家開發出簡約大方的form表單。

下圖是一個典型的element-ui的form

這里是上面表單的layout部分的代碼截圖

下面是它的表單驗證的部分

具體請參考element-ui的官方文檔

https://element.eleme.cn/#/zh-CN/component/form

可以說element-ui在很大程度上，幫大家用最少的代碼 完成了產品級表單頁面的開發。但是我們依然要處理大量的layout的代碼，而這些代碼看起來都是重復的代碼，自己寫雖然靈活度高，但是有沒有辦法自動完成呢。而且使用element-ui我們依然是要處理表單提交，以及編輯時候的數據拉取，這些事實上在各個表單中，也都是雷同的工作，不同的表單，處理方式應該都是一樣的，僅僅是 提交數據的接口不一樣，基于這個總結，我們可以做一個 表單組件，通過url指定要提交數據的位置，通過inputs傳入表單輸入項目的定義，然后讓這個form組件 自動完成layout繪制，數據拉取，表單驗證，數據提交等一些列動作。

tsyvue中定義的 sy-form表單就完成了我上面描述的工作。

http://tsy.zone/tsyvue/sy-form

tsyvue是為了進一步簡化項目開發，根據本人多年的開發經驗，提煉出項目中大量的共通代碼形成的擴展組件庫，通過npm發布，大家可以在自己的vue工程下運行以下命令來安裝

npm install tsyvue -S

通過tsyvue的sy-form構建一個用來 新建數據據的表單，layout的部分只要提供如下代碼即可。

sy-form(:inputs='formInputs' url='/example/form/url')

這里模板部分使用的pug語言，相較html更加簡潔。

可以看到，sy-form僅僅接收了一個url，表示最終數據要提交的位置。以及inputs，定了表單輸入項目，剩下繪制表單，驗證數據，提交數據，就都交給sy-form來完成了。

下面時input定義的例子

目前sy-from能夠滿足大部分場景的需求，下圖時基于sy-form繪制的表單的例子。

可以看到支持input radio select checkbox datepicker等多種輸入框，這里面的 單選按鈕 多選按鈕 下拉框 都是 tsyvue 的 sy-options組件渲染的，具體如何使用，請參考tsyvue的文檔，并下載例子調試

sy-options是備選項，可以通過type指定外觀，外觀 支持 下拉列表，單選按鈕，復選按鈕等，有單選和多選模式，至此從接口獲取備選項，或者前端提供備選項。詳細用法請參考http://tsy.zone/tsyvue/sy-options

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

概念還是有點多，有一些概念可能比較新，如果熟悉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 ）