EAV模型（实体-属性-值）的设计和低代码的处理方案（3）-- 实体属性定义及前端列表展...

前面两篇随笔介绍了EAV模型（实体-属性-值）的设计思路和Winform前端对于通用查询的处理，本篇随笔继续深入EAV模型（实体-属性-值）设计的探讨，介绍实体属性的定义，以及根据不同属性的定义构建不同的输入控件处理，以及列表界面的展示。旨在结合关系型数据库的熟练使用、性能优势和MongoDB数据库的弹性化文档处理特点，为低代码的处理方案提供一个实用的思路供参考。

1、实体属性定义

根据实体定义的一些特性，我们设计了下面的定义界面，主要就是对实体类属性的各种类型或者数据关联处理进行更好的维护，以及控制属性的可排序、可查询、是否可用、是否只读、是否隐藏值、是否必填等常规特性。

在通用的列表展示的时候，我们会根据属性的定义信息来统一展现不同的控件以及相关的属性设置，如常规可以根据储存类型来定义不同的控件输入，如文本、多文本、日期、整形、浮点型等数据，进一步还可以绑定下拉列表（动态字典、静态列表或者在字段自身值列表），也可以选择在选择字典的时候，复制某些值，或者在选择其他业务表的时候，同步复制关联的值等等，以及可以再前端类型进一步细化定义一些类型，如选择系统用户、系统机构、系统角色、查看附件、系统业务编码等等，这些内置的处理能够更贴切的符合实际系统的数据选择需求。

例如对于一些常规的字段属性（如产品名称），我们默认保留存储类型为varchar即可。

 而对于一些需要引用字典信息的，我们可以选择设置系统字典类型，如下所示。

而对于需要在数据录入的时候设置为下拉列表的方式（单选或者复选），并指定动态字典的，也可以实现。

前端的输入类型，有复选框、单选框组、评分控件、下拉列表、系统用户、系统角色、系统机构、系统附件、系统业务表编码 等选项，分别对应不同的控件界面录入处理。

我们选中通用的下拉列表，可以进一步指定是单选还是多选，并且数据来源可以为静态、动态、字段所有唯一值等不同的方式。 

如果我们定义了很多不同的实体类型业务表，那么如果需要主从表中选择复制某些字段，如何实现呢，通过上面的表选择设置即可实现。

2、WInform前端列表展示和数据录入处理

有了上面的准备定义工作，我们就可以为通用的EAV列表界面展示进行处理了，常规的列表界面分为单业务表的显示（如产品信息），以及主从表的业务显示（如订单和订单明细），如下界面所示。

单业务表的显示（如产品信息）

可以看到，这个列表的展示和常规开发的业务表显示没有太大的差异，也可以根据字段进行查询，以及进行自定义条件查询、或者进行高级查询。

 主从表的业务显示（如订单和订单明细）

 这两种不同的数据展示方式，自动根据系统属性设置关联进行动态创建（在属性定义的时候，指定了包含的明细对象）。

有了列表信息的动态展示，我们还需要确定每行记录的数据录入控件类型。

前面介绍了界面控件录入的类型，常规可以根据储存类型来定义不同的控件输入，如文本、多文本、日期、整形、浮点型等数据，进一步还可以绑定下拉列表（动态字典、静态列表或者在字段自身值列表），也可以选择在选择字典的时候，复制某些值，或者在选择其他业务表的时候，同步复制关联的值等等，以及可以再前端类型进一步细化定义一些类型，如选择系统用户、系统机构、系统角色、查看附件、系统业务编码等等。

对于整数或者带有小数点的浮点数，可以使用SpinEdit的输入来录入数值内容，如下所示，并可以定义设置显示的格式。 

同理对于日期类型，一样也是构建一个DateEdit控件用来录入数据，如下所示。

对于一些录入，有时候根据自身字段已有的数据列表进行选择录入，如下所示。

这个字段选择的时自身的值列表配置，如下是它的属性定义。

对于复选框、评分控件，也是根据配置信息，构建对应的录入控件的，如下界面所示。

对于系统用户、角色、机构的选择信息，我们可以根据用户是否允许多选来构建选择界面，定义好选择用户、角色、机构的界面即可，如下所示。

选择机构的界面如下所示。

 选择角色的界面类似（多选出现复选框），如下面所示。

 我们也可以指定属性为系统的附件，

 从而在列表显示并编辑的时候，接受系统上传的附件并显示附件的数量

单击按钮，可以打开查看记录的附件的列表信息。 

 另外，对于一些业务编码，我们也可以内置进行快速生成，使用系统配置好的生成编码规则，能够更好的符合我们实际的需求。

 系统业务编码规则管理是我们系统业务中的一个通用模块，可以引用它进行生成即可。

 这样我们在创建订单的时候，可以根据这个约定好的规则进行生成订单编码，是不是很方便？

3、动态业务菜单的定义

 上面我们介绍了实体类型的属性定义，以及通用的EAV数据列表界面展示，包括单业务列表界面，以及主从表界面的展示，并已经完成了各种常规输入控件类型的处理，包括系统字典、系统用户、系统角色、系统机构、系统附件、系统业务编码规则等，基本上覆盖了我们大多数的业务录入的需求了。

完成了上面的那些工作，我们来考虑动态业务菜单的问题，动态菜单是系统的一个管理模块，管理系统所有可用的菜单，并可以根据不同的角色授权不同的菜单，从而实现更加个性化的系统界面展示。

前面介绍了可以定制不同的业务实体类型，如下界面定义了很多不同的业务实体类型。

随着我们业务定义的变化，肯定会定义更多的实体类型，那么我们就要考虑动态菜单与具体的业务实体类型结合的问题了。

通过结合一个特定业务的菜单和一个特定的实体类型，我们就可以让系统打开一个业务的列表界面显示，从而实现常规的菜单元素的管理和分配了。

我们改造一下传统的菜单定义，我们只需要确定这个菜单项目为EAV的业务菜单和具体的绑定实体类型ID即可，如下界面所示。

我们通过再菜单编辑/新增界面中，指定菜单为EAV模式菜单，并确定好关联的实体类型ID（可以通过弹出框选择），从而创建一个EAV业务菜单即可。

同理，对于订单和订单明细的主从表列表业务，也是通用的处理方式，如下界面所示。

这样，我们在动态菜单中单击处理，就可以传递对应的实体类型ID给具体的窗体，并通过实体类型ID进行对应的初始化和显示记录即可，如下是单表的EAV模式的产品信息表的显示和录入处理界面。

下面则是主从表的（订单和订单明细表）的显示和录入处理界面。 

这样，通过直接配置而不需要编码，就可以实现常规业务表的设计，并可以结合动态菜单的方式，给客户进行开发，可以快速根据客户的需求进行增加或者修改字段，调整字段录入方式，顺序，可用等等，实现快速开发的响应。

同时，由于数据记录是存储在MongoDB的数据库上，即使数据量很大，也是能够高性能的进行响应，减少了关系型数据库在多表联合的弊端，同时还能利用数据文档的可修改性等突出特点，极大的减少编码的开发出来，可以说基本是零代码的开发方式。 

深入一点，我们可以记录每个字段的修改日志，增加每个字段对不同人员的可见性（可访问性）、可修改性等进行控制，从而实现更加弹性化的展示和录入的处理方式。