一二三应用开发平台应用开发示例（2）——创建应用、模块、实体及配置模型

创建应用

文档管理系统对于开发平台是一个业务应用。
业务应用是通过平台内置的数据字典来维护的，因此访问系统管理模块下的数据字典管理功能，在实体配置分组下找到“应用编码”，点击行记录上的“字典项”。

在打开的新窗口中，在原有开发平台的基础上，新建1条文档管理系统的记录，注意遵循常量值的命名规范，使用EDOC，如下图所示：

创建模块

访问系统管理模块下的“模块”功能，新建一条记录，注意应用选择上面新建的“文档管理系统”，编码输入edoc，会对应到包名，包路径输入tech.abc.edoc，缩略码为ed，平台依据实体生成库表时，会将缩略码作为库表的前缀。

新建实体

在完成应用与模块的配置后，以文件夹为例，进行实体配置工作。
访问实体配置模块下的实体菜单，点击新建按钮，选择上面创建的“文档管理”模块，输入实体的名称和编码，平台在生成代码时将编码作为实体名，因此规范遵循java类的命名规范，首字母大写，保存后完成创建工作。

配置数据模型

在实体列表中通过查询功能，找到新建的“文件夹”实体，点击行记录上的“配置”按钮，如下图所示：

打开实体配置页面，如下图所示：

如左侧导航所示，实体配置分为两大步，数据模型和视图，前者对应着数据库表、实体类等，后者对应着前端页面，默认进入的是数据模型。
数据模型是实体重要的元数据，系统会参照数据模型的配置信息，生成数据库表，以及实体类、服务接口、服务实现、控制器和视图对象类。
为了提升开发效率，平台会参照实体配置信息自动生成1个同名的数据模型。

补充说明一点，实体与数据模型一对一只是最常见的一种情况，实际业务需求存在一对多的情况，如销售订单，不仅有订单，还有订单明细，可以使用平台添加新的数据模型。

设置自关联

当前配置的“文件夹”实体，通过父级可以形成树形结构，也就是自关联关系，因此这里需要点击行记录上的“修改”按钮，将“是否自关联”由否调整为是，如下图所示。

对于自关联的实体模型，平台会在代码生成环节做一些额外的逻辑处理，在控制器里增加树形数据的接口处理，如下所示：

    <#if entityModelSelfReferenceFlag=="YES">//region 树操作/*** 获取树数据** @return*/@GetMapping("/tree")@PreAuthorize("hasPermission(null,'${package.ModuleName}:${entity?uncap_first}:query')")public ResponseEntity<Result> tree() {QueryWrapper<${entity}> queryWrapper = new QueryWrapper<>();<#list entityModelPropertyList as item><#if item.code=="status">queryWrapper.lambda().eq(${entity}::getStatus, StatusEnum.NORMAL.toString());</#if><#if item.code=="orderNo">// 附加按照排序号排序queryWrapper.orderByAsc(TableFieldConstant.DEFAULT_SORT_FILED);</#if></#list>List<${entity}> list = ${entity?uncap_first}Service.list(queryWrapper);// 转化成树结构数据List<TreeVO> treeList = list.stream().map(e -> convert2TreeVO(e)).collect(Collectors.toList());List<TreeVO> tree = TreeUtil.buildTree(treeList, TreeDefaultConstant.DEFAULT_TREE_ROOT_PARENT_ID);return ResultUtil.success(tree);}/*** 转换为树视图对象*/private TreeVO convert2TreeVO(${entity} entity) {TreeVO tree = new TreeVO();tree.setId(entity.getId());tree.setParentId(entity.get${parentPropertyCode?cap_first}());tree.setLabel(entity.get${mainPropertyCode?cap_first}());return tree;}//endregion</#if>

配置属性

数据模型的属性，对应着java中实体类的属性，同时也对应着数据库中的字段。

上级

点击数据模型行记录上的“配置属性”按钮，打开属性列表，点击“新增”按钮，创建一条“上级”的属性。

该属性用于自关联，所以需要将“是否上级属性”的值设置为“是”。平台通过该标识来寻找上级关系，从而构建树状层次结构。

注：上级实际数据类型应该选择“实体”，但关联实体相对比较复杂，作为介绍平台使用的引导性范例，上来就是一个复杂的属性配置，不利于入门，因此这里先做基本的文本属性处理，完成基本的配置后，再做调整。
个别属性不需要存储到数据库，如多个属性组合成的属性则可以将“是否库表存储”的值由默认的是调整为否。

名称

按照同样操作新增名称属性，如下图所示：

注意红框标记的三处设置。
是否可为空：设置为否，平台会在生成代码时对前端和后端都附加必填验证，实现的效果也就是文件夹名称不能为空。
是否唯一：设置为是，且选择唯一性参照为“上级”，平台会在后端服务保存数据时附加验证“同一上级节点下不能存在名称相同的节点”，实现的效果也就是文件夹下不能存在两个名称相同的文件夹。
是否主属性：设置为是，主属性是指该实体的主要显示属性，当该实体作为关联对象时，标记为主属性的属性作为主要显示内容，例如，文件夹的上级也是文件夹，关联上级后，会显示上级文件夹的名称。

父级模型

通过上面操作，为文件夹数据模型设置了2个属性：上级、名称，然后就结束了。
实际上，平台会为实体自动附加一些通用公共属性，如标识、创建人、创建时间、修改人、修改时间、版本号、逻辑删除标识位，并不需要人工来对每个实体配置，如何实现的呢？通过模型继承来做到这一点的，这里的继承，与面向对象中的继承是同一个实现思路。

在数据模型的属性中，可以选择父级模型，系统预置了三个模型：标识模型（只有标识id属性）、业务模型（继承于标识模型，附加了创建人、创建时间、修改人、修改时间、乐观锁、逻辑删除标识位属性）、流程模型（继承于业务模型，附加了与流程相关的一系列发起人、流程状态等属性）。

并且模型既可以通过继承现有模型的方式扩展，也可以添加新的独立模型，从而达到复用的目的。