自定義表單設計的目標是不編寫程式碼，由設計人員在介面設計表單配置，使用者就能使用具體的功能模組了，對於這個目標，首先要解決的就是資料儲存以及資料庫與表單之間的對映問題。

　　平時如果使用過程式碼生成工具，應該對大體的過程有些認識。要麼從資料庫讀取已經定義好的表結構，工具生成實體部分程式碼，或者是與框架強相關的不同層次的服務程式碼；要麼從配置檔案，再反向生成資料庫程式碼或者業務相關程式碼；還有可能先定義實體類，再生成其他部分程式碼。生成程式碼之後，再拷貝到具體的程式碼目錄。

　　這裡設計的實體模型與程式碼生成工具有部分思路還是相同的，但自定義表單賦予了他更多的功能與職責，首先，他需要面向使用者，使用者、開發人員和設計人員可以在介面上隨時修改實體資料，系統動態同步資料庫與實體模型之間的對映（如果系統已經在執行，實體模型對應的資料庫表資料量比較大，則通過系統自動修改表結構可能會存在問題，需要DBA把資料庫表修改好，再同步實體模型）；其次，執行時CRUD等與資料儲存相關操作，需要依賴此實體模型，比如自動生成Id、自動新增審計日誌、動態生成各種Sql語句、自動方法驗證等；再者，可以定義與實體模型相關的動態方法執行，比如執行各種基礎的增冊改查以及分頁獲取資料等，或者執行自定義的Sql語句，還可以執行反射或者微服務呼叫定義等。總之，這裡的實體模型做為自定義表單的基礎，承擔了更多的職責。

　　下面介紹資料庫設計

　　與實體物件模型對應的資料庫設計有三張表，SpriteObject，主要管理資料庫表資訊，並與動態生成的實體資料庫表一一對應；ObjectProperty，主要管理資料庫表字段資訊，並與執行時動態生成的資料庫表字段一一對應；ObjectMethods，主要管理執行時方法的呼叫（自定義表單將大多數常規的資料庫表操作的Sql語句指令碼執行都提供了預設的方法實現，提供給表單或者檢視規則使用，大多數常規的CRUD操作不需要另外再單獨定義方法，但對於特殊的業務還是需要自定義Sql指令碼執行或者寫程式碼完成，但都是通過ObjectMethods管理，並提供給表單規則引擎使用）。ObjectMaps（廢棄），定義實體與實體也就是資料庫表與表之前的關聯關係，但同步維護這個關係會大大增加系統的複雜程度，這裡廢棄了，通過後面介紹的規則引擎來管理，CommonParams，方法引數管理，主要管理方法呼叫的引數，引數設計到實體巢狀，也會大大增加系統的複雜度，這部分也交給規則執行引擎來控制。　　

　　核心欄位介紹：

SpriteObject，實體物件

• Name，定義實體名稱，與資料庫表名一一對應。
• ApplicationCode，系統Code，可以按照不同微服務管理各個功能模組。
• Version，版本號，每次修改之後，重新生成版本號，SpriteObject使用非常平凡，需要將SpriteObject相關的資料儲存到快取中，依賴他的地方需要判斷版本號。
• KeyType，定義主鍵型別，建立資料庫或者新增執行時資料時，根據此欄位動態生成Id以及Id值。
• PropertyJsons，屬性資料Json儲存，為了提高系統整體效能，將屬性相關資料序列化到此欄位，讀取與訪問實體欄位時，不再需要讀取ObjectProperty表資料。
• IsTree，是否為樹，系統自動生成PId、Path、Code、Title等值，並在執行時自動管理
• CreateAudit，自動新增建立CreatorId和CreationTime審計日誌及欄位，並在執行時自動管理

ObjectProperty物件屬性管理

• Name，欄位名稱，與資料庫欄位一一對應
• 其他欄位都比較好理解

ObjectMethods方法管理

　　常規的Sql方法已經內建到了系統中，比如增刪改查獲取列表獲取分頁資料等，直接使用方法名稱即可，常規功能模組，大多數情況這些內建的Sql語句都能夠滿足，這裡只是定義常規Sql操作不能滿足的情況，比如各種統計分析等。

• MethodExeType 方法執行型別，可以是Sql語句，反射執行，微服務呼叫
• MethodExeContent方法執行內容，Sql語句時，執行的是Sql命令（多條時，用";"號隔開）；反射時，傳遞程式集以方法，通過反射執行；微服務為微服務名稱

　　這篇文章主要是介紹實體模型的整體設計思想，後續文章會結合程式碼，介紹實體模型與資料庫表之間一一對應關係的實現以及自定義表單核心之一的執行時動態方法執行。

&n