自定義表單引擎 架構及核心模組設計
企業自定義表單引擎解決方案
架構及核心模組設計
先總體介紹一下大概的架構和核心模組設計。先上一張整體設計圖
概念還是有點多，有一些概念可能比較新，如果熟悉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的動態控制元件比較死板，動態控制元件不能動態新增指令，還有其他很多限制，基本上斷了自定義表單的路了。
.net core 自定義表單 企業級自定義表單引擎解決方案（十）--快取設計2 摘要：新年伊始，萬物皆生機，然冠未去，美帝相向，於華夏之子，吾輩當自強。 這篇文章接上一篇文章，主要介紹快取的程式碼實現 後端本地快取 之前介紹的將自定義表單資料全部儲存到應用程式記憶體中，任何自定義表單資料更新之後，都重新整理記憶體快取，分散式部署涉及到快取同步重新整理問題。 全域性本地快取容器設計 用執行緒安全的字典C 閱讀全文 posted @ 2022-02-09 18:50 spritekuang 閱讀(484) 評論(0) 推薦(2) 編輯 企業級自定義表單引擎解決方案（九）--快取設計 摘要：新年伊始，萬物皆生機，然冠未去，美帝相向，於華夏之子，吾輩當自強。 快取對於任何一個系統來說，都是繞不開的一個話題，快取設計好了對系統整體的效能往往是指數級的提升，但如是設計不好，對系統的穩定性和效能都是災難性的影響，並直接影響系統整體的架構設計，這篇文章主要對自定義表單後端部分快取的設計進行討論， 閱讀全文 posted @ 2022-01-26 18:36 spritekuang 閱讀(364) 評論(0) 推薦(3) 編輯 企業級自定義表單引擎解決方案（八）--表單模型管理 摘要：這段時間陸續收到一些小夥伴的資訊，對流程引擎和自定義表單比較感興趣，內心還是比較欣喜的。多數人還是對elsa實現的流程引擎比較感興趣，要原始碼，這部分內容原本是有打算把原始碼開源出來的，但後來發現elsa的版本升級到了2.0之後，與之前的程式碼相差比較遠，要重構的話，前後端需要改很多東西，elsa1.x的 閱讀全文 posted @ 2021-12-22 21:50 spritekuang 閱讀(582) 評論(1) 推薦(8) 編輯 企業級自定義表單引擎解決方案（七）--檢視模型管理 摘要：實體模型，檢視模型，表單模型，表單規則引擎，這幾部分內容是自定義表單核心內容，之前的文章已經介紹了實體模型，這篇文章介紹一下檢視模型管理。 我們平時見到的一些管理系統或者多數程式設計師做的一些CRUP操作，比如我們接觸最多的列表管理、表單Form管理、樹管理等，這些功能在一個後臺管理系統中最為常見也最為 閱讀全文 posted @ 2021-09-09 15:22 spritekuang 閱讀(678) 評論(0) 推薦(1) 編輯 企業級自定義表單引擎解決方案（六）--工作流掛接表單 摘要：自定義表單可以掛載到流程引擎，也可單獨存在，本文介紹自定義表單掛接流程引擎案例，流程引擎採用開源的框架elsa，並對部分程式碼做了修改以適應中國國內的審批業務，流程設計器也是基於elsa提供的前端實現框架，但全部移植到vue版本中以適應自身框架的需要。 流程引擎應用範圍： 1.關鍵業務流程：訂單、報價 閱讀全文 posted @ 2021-07-05 09:49 spritekuang 閱讀(953) 評論(2) 推薦(4) 編輯 企業級自定義表單引擎解決方案（五）--自定義表單典型業務案例 摘要：這篇文章結合案例再來直觀的感受一下自定義表單的應用，純技術上的應用會比較枯燥一些，後面再對大的設計細節進行展開。 我們平時的業務絕大多數都是圍繞著單表、一對多關係、多對多關係，以及擴充套件開來的一對多對多、一對一、一(樹結構)對多等展開。 如果把這些關係做成自定義表單模板，則只需要幾步就能夠配置出滿足絕 閱讀全文 posted @ 2021-07-05 09:47 spritekuang 閱讀(1177) 評論(1) 推薦(2) 編輯 企業級自定義表單引擎解決方案（四）--實體物件模型實現 摘要：實體物件模型與資料庫對應實現 主要是解決實體物件模型與資料庫之間的一一對應，在介面上新增實體物件模型，增加欄位，則同步管理業務實體資料庫表結構，主要的思路就是介面上修改了實體模型，同步執行修改資料庫表結構的Sql語句(已經運行了一段時間的業務表，需要DBA實現修改資料庫再修改實體模型)，介面大概如下 閱讀全文 posted @ 2021-03-14 22:35 spritekuang 閱讀(1024) 評論(2) 推薦(1) 編輯 企業級自定義表單引擎解決方案（三）--實體物件模型設計 摘要：自定義表單設計的目標是不編寫程式碼，由設計人員在介面設計表單配置，使用者就能使用具體的功能模組了，對於這個目標，首先要解決的就是資料儲存以及資料庫與表單之間的對映問題。 平時如果使用過程式碼生成工具，應該對大體的過程有些認識。要麼從資料庫讀取已經定義好的表結構，工具生成實體部分程式碼，或者是與框架強相關的不 閱讀全文 posted @ 2021-03-13 23:03 spritekuang 閱讀(1400) 評論(0) 推薦(2) 編輯 企業級自定義表單引擎解決方案（二）--架構及核心模組設計 摘要：先總體介紹一下大概的架構和核心模組設計。先上一張整體設計圖 概念還是有點多，有一些概念可能比較新，如果熟悉K2自定義表單，可能比較好理解一些。程式碼地址：https://gitee.com/kuangqifu/sprite，或者QQ交流：523477776 對核心的一些功能模組進行總體介紹如下(用.n 閱讀全文 posted @ 2020-11-24 21:43 spritekuang 閱讀(2806) 評論(4) 推薦(3) 編輯 企業級自定義表單引擎解決方案（一）--總體介紹 摘要：大家回想一下，有多少軟體公司，多少專案，多少初中級程式設計師在做著CRUD方面的一些重複而繁雜的工作呢？對於公司專案來說，可能60-70%的成本都花費在CRUD方面的開發管理上，對於程式設計師職業生涯來說，可能也有60-70%的工作也是在做著一些CRUD方面的工作，無可否認，作者也是。 如果這些CRUD相關 閱讀全文 posted @ 2020-11-24 19:56 spritekuang 閱讀(2924) 評論(6) 推薦(7) 編輯
公告
暱稱： spritekuang園齡： 12年9個月
粉絲： 28
關注： 2 +加關注
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
|---|---|---|---|---|---|---|---|---|---|
| 27 | 28 | 1 | 2 | 3 | 4 | 5 | |||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 | |||
| 13 | 14 | 15 | 16 | 17 | 18 | 19 | |||
| 20 | 21 | 22 | 23 | 24 | 25 | 26 | |||
| 27 | 28 | 29 | 30 | 31 | 1 | 2 | |||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | |||
搜尋
常用連結
我的標籤
隨筆分類
隨筆檔案
- 2022年2月(1)
- 2022年1月(1)
- 2021年12月(1)
- 2021年9月(1)
- 2021年7月(2)
- 2021年3月(2)
- 2020年11月(2)
- 2020年10月(2)
- 2019年5月(17)
閱讀排行榜
- 1. 企業級自定義表單引擎解決方案（一）--總體介紹(2923)
- 2. 企業級自定義表單引擎解決方案（二）--架構及核心模組設計(2801)
- 3. 企業級工作流解決方案（一）--總體介紹(2276)
- 4. 企業級自定義表單引擎解決方案（三）--實體物件模型設計(1399)
- 5. 企業級工作流解決方案（十三）--整合Abp和ng-alain--資料庫讀寫分離(1279)
評論排行榜
- 1. 企業級自定義表單引擎解決方案（一）--總體介紹(6)
- 2. 企業級自定義表單引擎解決方案（二）--架構及核心模組設計(4)
- 3. 企業級工作流解決方案（十三）--整合Abp和ng-alain--資料庫讀寫分離(3)
- 4. 企業級自定義表單引擎解決方案（六）--工作流掛接表單 (2)
- 5. 企業級自定義表單引擎解決方案（四）--實體物件模型實現(2)
推薦排行榜
- 1. 企業級自定義表單引擎解決方案（八）--表單模型管理(8)
- 2. 企業級自定義表單引擎解決方案（一）--總體介紹(7)
- 3. 企業級工作流解決方案（十三）--整合Abp和ng-alain--資料庫讀寫分離(5)
- 4. 企業級自定義表單引擎解決方案（六）--工作流掛接表單 (4)
- 5. 企業級自定義表單引擎解決方案（九）--快取設計(3)
最新評論
- 1. Re:企業級自定義表單引擎解決方案（四）--實體物件模型實現
-
同問
- 2. Re:企業級自定義表單引擎解決方案（五）--自定義表單典型業務案例
-
前端部分有計劃開源不？
- 3. Re:企業級自定義表單引擎解決方案（八）--表單模型管理
-
規則部分建議再寫文章描述一下思路呢
- 4. Re:企業級自定義表單引擎解決方案（一）--總體介紹
-
想法是好的，不知道複雜一點的業務能不能支援。
- 5. Re:企業級工作流解決方案（十六）--工作流--工作流實體模型
-
大佬。elsa 相關的設計能共享一下嗎~~~
先總體介紹一下大概的架構和核心模組設計。先上一張整體設計圖
概念還是有點多，有一些概念可能比較新，如果熟悉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的動態控制元件比較死板，動態控制元件不能動態新增指令，還有其他很多限制，基本上斷了自定義表單的路了。
Copyright © 2022 spritekuang