- 1next 14 appRouter redux数据持久化_nextjs redux 持久化存储
- 2mac与windows服务器 访问和共享
- 3Android 15全面解读：性能飙升、隐私守护与智能生活新纪元_安卓15
- 4标题：怎样通过Dialogflow构建一个聊天机器人？React版。_dialogflow机器人
- 5连接Mongodb数据库的步骤以及注意事项_如何连接mongodb数据库
- 6小程序公告php实现,小程序两种滚动公告栏的实现方法
- 7Git仓库完整迁移全过程_gitee 将a仓库的克隆到b仓库
- 8FP6381AS5CTR原厂SOT23-5 1.2A同步降压IC DC-DC变频器
- 9STM32参考代码，编译时出现“cannot open source input file, no such file or directory"错误
- 10微信小程序用户隐私保护指引设置指南_mp后台-设置-基本设置-服务内容声明-用户隐私保护指引]中声明“剪切板”隐私收集
带你一步步实现低代码开发平台——整合接口平台，架构优化，使用低代码配置模块、实体、模型_低代码平台接口配置要简单易用
赞
踩
之前开源了一套通用接口平台，详见专栏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项，使用单选按钮组，操作简便，显示直观，如字典项多，则会占用大量页面显示面积，这时候，使用下拉列表更佳。
字典类型选中后，默认值也会自动加载，可根据实际情况选择是否需要设置默认值，以及将哪个字典项作为默认值。
所有属性配置完成如下图所示。
今天先到这，视图部分超级复杂，留待下篇专题说明。
开发平台资料
平台名称：一二三开发平台
简介： 企业级通用开发平台
设计资料：csdn专栏
开源地址：Gitee
开源协议：MIT
欢迎收藏、点赞、评论，你的支持是我前行的动力。
