企业级自定义表单引擎解决方案（三）--实体对象模型设计

　　自定义表单设计的目标是不编写代码，由设计人员在界面设计表单配置，用户就能使用具体的功能模块了，对于这个目标，首先要解决的就是数据存储以及数据库与表单之间的映射问题。

　　平时若是使用过代码生成工具，应该对大致的过程有些认识。要么从数据库读取已经定义好的表结构，工具生成实体部分代码，或者是与框架强相关的不一样层次的服务代码；要么从配置文件，再反向生成数据库代码或者业务相关代码；还有可能先定义实体类，再生成其余部分代码。生成代码以后，再拷贝到具体的代码目录。

　　这里设计的实体模型与代码生成工具备部分思路仍是相同的，但自定义表单赋予了他更多的功能与职责，首先，他须要面向使用者，用户、开发人员和设计人员能够在界面上随时修改实体数据，系统动态同步数据库与实体模型之间的映射（若是系统已经在运行，实体模型对应的数据库表数据量比较大，则经过系统自动修改表结构可能会存在问题，须要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命令（多条时，用";"号隔开）；反射时，传递程序集以方法，经过反射执行；微服务为微服务名称

 

　　这篇文章主要是介绍实体模型的总体设计思想，后续文章会结合代码，介绍实体模型与数据库表之间一一对应关系的实现以及自定义表单核心之一的运行时动态方法执行。