带你一步步实现低代码开发平台——整合接口平台，架构优化，使用低代码配置模块、实体、模型网站首页 技术教程

带你一步步实现低代码开发平台——整合接口平台，架构优化，使用低代码配置模块、实体、模型

学海无涯，行者无疆 2024-06-17 10:19:58

简介带你一步步实现低代码开发平台——整合接口平台，架构优化，使用低代码配置模块、实体、模型

之前开源了一套通用接口平台，详见专栏https://blog.csdn.net/seawaving/category_11610162.html。

现在，将通用接口平台作为一个模块，整合到新的应用开发平台当中来，由通用接口平台统一对外暴露应用系统的API数据接口，以及推送事件消息。

原架构

之前的的通用接口平台，主要由两个模块组成，一个是platform-cip（cip是common interface platform缩写），即接口平台的主体，另外一个是platform-cip-common，被platform-cip依赖。
platform-cip-common之所以需要独立出来，是因为基于netty的消息服务，platform-cip相当于消息的服务端，还有一个相对独立的客户端，服务端和客户端有些类需要公用，所以抽取出来作为公共模块。

架构优化

实际上，接口平台的主体，platform-cip，里面包含了三块内容：
1.对外提供API数据接口
2.基于netty的web socket服务端
3.平台自身基础数据的维护，如应用、API服务清单、消息服务清单、订阅等。
本次整合，不是简单的迁移，而是包括重构优化，将platform-cip进一步拆分为三个模块。

整合工作

1.创建模块

第一步，创建4个模块，都以platform-cip作为前缀
platform-cip-common：公共基础
platform-cip-api：API服务
platform-cip-message：消息服务
platform-cip-manage：平台管理

2.迁移与拆分模块

迁移common模块：这是个前置依赖的基础模块，迁移整合比较简单，主要工作就是改下依赖时引用的包名和路径。
拆分platform-cip模块：一分为三。
4个模块内关系为manage依赖common，api和manage相互独立，但都依赖于manage。
代码重构：将原位于api位置的实体类ApiRequest和ApiResponse,向上抽取到了common模块

这4个模块，只有manage模块有前端页面，其他三个都是类库。下面使用开发平台的低代码配置功能，来重写该模块，顺便也介绍下低代码配置功能的使用方法和注意事项。

重新实现manage模块

先来回顾下整体框架与步骤，如下图所示。

接下来就具体来说说具体步骤和注意事项。

1.新建模块

属性	说明
应用	模块隶属于哪个应用，考虑到应用数量有限，属性也较少，没新建实体，使用数据字典来做一个简易化管理
名称	模块中文名称，没啥好说的
编码	模块编码，关键属性，用做唯一性标识，同时也是前端的目录名和后端模块的包名
缩略码	模块的缩略码，用于该模块库表的前缀
包路径	模块所处的包路径
排序	用来排序，下文不再重复列出
备注	就是备注，下文不再重复列出

上面这个例子中，因为cip本身就是缩写了，体现不出编码和缩略码的差别来。
再举一个例子，比如系统管理模块，编码是system，缩略码是sys，编码system用于前端目录名和后端的包名，缩略码sys用于该模块库表的命名前缀。

创建模块过程中，发现原来重构的manage模块的包路径没有遵循低代码配置的规范，包路径多了一段manage出来。这个简单，重构即可，把包路径manage去除，模块名保持manage不变，接口平台拆出来的4个模块，实际只有manage模块有前端功能对应，其他三个模块都是类库，所以将其视为接口平台主体也名副其实。

2.新建实体

先选一个简单的实体来做实例。
接口平台首先需要维护对接的应用数据，这里就以应用这个实体为例。

属性	说明
模块	实体隶属的模块，从上面第1步配置的数据列表中选择
名称	实体中文名称
编码	实体的英文编码，复用，作为后端实体类名、库表名
作者	用于标注实体的开发人员，会生成代码类注释中@author属性

开发平台内置了处理逻辑，在保存实体的时候，会自动创建一个同名的实体模型，并将其自动设置为主模型，减少重复性工作，提升开发效率。

点击保存按钮，返回列表，点击应用这行右方的配置按钮，进入实体配置页面，如下：

左侧是导航，分为两块，一是数据模型，二是视图。

3.配置数据模型

属性	说明
父模型	通过继承理念实现模型的复用与扩展，预置了业务模型，包含了标识、创建人、创建时间、修改人，修改时间、逻辑删除标志位、版本号（乐观锁控制），继承该模型将自动具备这些公用属性，可扩展
名称	中文名称
编码	英文编码，复用，作为库表名称（实际是库表名称的后半段，前面会加模块缩略码，避免出现不同模块下存在同名实体导致库表名重复问题）
是否主模型	每个实体，下面可能有多个模型，需要标记一个主模型，作为主体，如销售订单实体，是由订单和订单明细两组成，这时候，将订单标记为主体
是否自关联	部分实体是自关联关系，如组织机构，标记自关联后，代码会在代码生成中进行额外处理，如在controller中增加获取树状结构数据的接口。

4.配置模型属性

行记录上点击“配置属性”按钮，打开模型属性配置功能，如下：

点击新增按钮，创建新属性：

属性	说明
名称	属性中文描述
编码	属性英文编码，对应java实体类中的属性，遵循小驼峰命名规范，平台依据该属性生成数据库字段名，驼峰命名风格自动转换为蛇形风格（全部小写，单词间使用下划线分隔）
数据类型	属性的数据类型，包括基本类型（如文本、整形、长整型、浮点数、日期时间等）和复杂类型（如数据字典、实体），可扩展
控件类型	属性的默认展示控件，随数据类型自动变化，如文本，对应普通文本、长文本和富文本。
最大长度	属性长度设定，对应库表字段长度设置。
默认值	默认值填充，新建实体时，服务层会自动读取配置，设置属性对应的默认值。
是否可为空	属性是否允许为空，如不能为空，生成vo对象时，会自动添加验证注解@NotBlank。
是否唯一	值是否唯一，如唯一，生成服务时，会在创建或修改前，自动生成数据验证逻辑。
唯一性参照	保持为空进行全局唯一验证，可选择本实体模型其他属性，代表该属性值下唯一，通常用于父子类型数据结构下，同一父级下不能重复。
是否主属性	标记是否为主属性，该属性视为实体的主要显示属性，当该实体用于其他实体关联时，将该属性作为显示值
是否上级属性	用于标记该属性是否关联到上级

这里的属性，有些看上去跟模型属性无关，比如控件类型，显示格式等，放到视图配置类更合适。之所以放到实体模型属性这里，是从开发效率的角度考虑。同一模型，会配置多个视图，多次使用属性，将属性的默认显示放到实体属性里配置后，简化视图环节配置，避免重复配置，提升效率。

同理，创建其他属性。

当数据类型选择数据字典时，会自动出现字典类型选择控件，选择系统中设置的数据字典。

控件类型也会出现下拉列表和单选按钮组，通常字典项少的情况下2-3项，使用单选按钮组，操作简便，显示直观，如字典项多，则会占用大量页面显示面积，这时候，使用下拉列表更佳。

字典类型选中后，默认值也会自动加载，可根据实际情况选择是否需要设置默认值，以及将哪个字典项作为默认值。