wuhuacong(伍華聰)的專欄

前面兩篇隨筆介紹了EAV模型（實體-屬性-值）的設計思路和Winform前端對于通用查詢的處理，本篇隨筆繼續深入EAV模型（實體-屬性-值）設計的探討，介紹實體屬性的定義，以及根據不同屬性的定義構建不同的輸入控件處理，以及列表界面的展示。旨在結合關系型數據庫的熟練使用、性能優勢和MongoDB數據庫的彈性化文檔處理特點，為低代碼的處理方案提供一個實用的思路供參考。

前面兩篇隨筆介紹了EAV模型（實體-屬性-值）的設計思路和Winform前端對于通用查詢的處理，本篇隨筆繼續深入EAV模型（實體-屬性-值）設計的探討，介紹實體屬性的定義，以及根據不同屬性的定義構建不同的輸入控件處理，以及列表界面的展示。旨在結合關系型數據庫的熟練使用、性能優勢和MongoDB數據庫的彈性化文檔處理特點，為低代碼的處理方案提供一個實用的思路供參考。

1、實體屬性定義

根據實體定義的一些特性，我們設計了下面的定義界面，主要就是對實體類屬性的各種類型或者數據關聯處理進行更好的維護，以及控制屬性的可排序、可查詢、是否可用、是否只讀、是否隱藏值、是否必填等常規特性。

在通用的列表展示的時候，我們會根據屬性的定義信息來統一展現不同的控件以及相關的屬性設置，如常規可以根據儲存類型來定義不同的控件輸入，如文本、多文本、日期、整形、浮點型等數據，進一步還可以綁定下拉列表（動態字典、靜態列表或者在字段自身值列表），也可以選擇在選擇字典的時候，復制某些值，或者在選擇其他業務表的時候，同步復制關聯的值等等，以及可以再前端類型進一步細化定義一些類型，如選擇系統用戶、系統機構、系統角色、查看附件、系統業務編碼等等，這些內置的處理能夠更貼切的符合實際系統的數據選擇需求。

例如對于一些常規的字段屬性（如產品名稱），我們默認保留存儲類型為varchar即可。

 而對于一些需要引用字典信息的，我們可以選擇設置系統字典類型，如下所示。

而對于需要在數據錄入的時候設置為下拉列表的方式（單選或者復選），并指定動態字典的，也可以實現。

前端的輸入類型，有復選框、單選框組、評分控件、下拉列表、系統用戶、系統角色、系統機構、系統附件、系統業務表編碼 等選項，分別對應不同的控件界面錄入處理。

我們選中通用的下拉列表，可以進一步指定是單選還是多選，并且數據來源可以為靜態、動態、字段所有唯一值等不同的方式。 

如果我們定義了很多不同的實體類型業務表，那么如果需要主從表中選擇復制某些字段，如何實現呢，通過上面的表選擇設置即可實現。

  

2、WInform前端列表展示和數據錄入處理

有了上面的準備定義工作，我們就可以為通用的EAV列表界面展示進行處理了，常規的列表界面分為單業務表的顯示（如產品信息），以及主從表的業務顯示（如訂單和訂單明細），如下界面所示。

單業務表的顯示（如產品信息）

可以看到，這個列表的展示和常規開發的業務表顯示沒有太大的差異，也可以根據字段進行查詢，以及進行自定義條件查詢、或者進行高級查詢。

 主從表的業務顯示（如訂單和訂單明細）

 這兩種不同的數據展示方式，自動根據系統屬性設置關聯進行動態創建（在屬性定義的時候，指定了包含的明細對象）。

有了列表信息的動態展示，我們還需要確定每行記錄的數據錄入控件類型。

前面介紹了界面控件錄入的類型，常規可以根據儲存類型來定義不同的控件輸入，如文本、多文本、日期、整形、浮點型等數據，進一步還可以綁定下拉列表（動態字典、靜態列表或者在字段自身值列表），也可以選擇在選擇字典的時候，復制某些值，或者在選擇其他業務表的時候，同步復制關聯的值等等，以及可以再前端類型進一步細化定義一些類型，如選擇系統用戶、系統機構、系統角色、查看附件、系統業務編碼等等。

對于整數或者帶有小數點的浮點數，可以使用SpinEdit的輸入來錄入數值內容，如下所示，并可以定義設置顯示的格式。 

同理對于日期類型，一樣也是構建一個DateEdit控件用來錄入數據，如下所示。

對于一些錄入，有時候根據自身字段已有的數據列表進行選擇錄入，如下所示。

這個字段選擇的時自身的值列表配置，如下是它的屬性定義。

對于復選框、評分控件，也是根據配置信息，構建對應的錄入控件的，如下界面所示。

對于系統用戶、角色、機構的選擇信息，我們可以根據用戶是否允許多選來構建選擇界面，定義好選擇用戶、角色、機構的界面即可，如下所示。

選擇機構的界面如下所示。

 選擇角色的界面類似（多選出現復選框），如下面所示。

 

 我們也可以指定屬性為系統的附件，

 從而在列表顯示并編輯的時候，接受系統上傳的附件并顯示附件的數量

單擊按鈕，可以打開查看記錄的附件的列表信息。 

 另外，對于一些業務編碼，我們也可以內置進行快速生成，使用系統配置好的生成編碼規則，能夠更好的符合我們實際的需求。

 系統業務編碼規則管理是我們系統業務中的一個通用模塊，可以引用它進行生成即可。

 這樣我們在創建訂單的時候，可以根據這個約定好的規則進行生成訂單編碼，是不是很方便？

 

3、動態業務菜單的定義

 上面我們介紹了實體類型的屬性定義，以及通用的EAV數據列表界面展示，包括單業務列表界面，以及主從表界面的展示，并已經完成了各種常規輸入控件類型的處理，包括系統字典、系統用戶、系統角色、系統機構、系統附件、系統業務編碼規則等，基本上覆蓋了我們大多數的業務錄入的需求了。

完成了上面的那些工作，我們來考慮動態業務菜單的問題，動態菜單是系統的一個管理模塊，管理系統所有可用的菜單，并可以根據不同的角色授權不同的菜單，從而實現更加個性化的系統界面展示。

前面介紹了可以定制不同的業務實體類型，如下界面定義了很多不同的業務實體類型。

隨著我們業務定義的變化，肯定會定義更多的實體類型，那么我們就要考慮動態菜單與具體的業務實體類型結合的問題了。

通過結合一個特定業務的菜單和一個特定的實體類型，我們就可以讓系統打開一個業務的列表界面顯示，從而實現常規的菜單元素的管理和分配了。

我們改造一下傳統的菜單定義，我們只需要確定這個菜單項目為EAV的業務菜單和具體的綁定實體類型ID即可，如下界面所示。

我們通過再菜單編輯/新增界面中，指定菜單為EAV模式菜單，并確定好關聯的實體類型ID（可以通過彈出框選擇），從而創建一個EAV業務菜單即可。

同理，對于訂單和訂單明細的主從表列表業務，也是通用的處理方式，如下界面所示。

這樣，我們在動態菜單中單擊處理，就可以傳遞對應的實體類型ID給具體的窗體，并通過實體類型ID進行對應的初始化和顯示記錄即可，如下是單表的EAV模式的產品信息表的顯示和錄入處理界面。

下面則是主從表的（訂單和訂單明細表）的顯示和錄入處理界面。 

這樣，通過直接配置而不需要編碼，就可以實現常規業務表的設計，并可以結合動態菜單的方式，給客戶進行開發，可以快速根據客戶的需求進行增加或者修改字段，調整字段錄入方式，順序，可用等等，實現快速開發的響應。

同時，由于數據記錄是存儲在MongoDB的數據庫上，即使數據量很大，也是能夠高性能的進行響應，減少了關系型數據庫在多表聯合的弊端，同時還能利用數據文檔的可修改性等突出特點，極大的減少編碼的開發出來，可以說基本是零代碼的開發方式。 

深入一點，我們可以記錄每個字段的修改日志，增加每個字段對不同人員的可見性（可訪問性）、可修改性等進行控制，從而實現更加彈性化的展示和錄入的處理方式。