之前开源了一套通用接口平台,详见专栏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进一步拆分为三个模块。
第一步,创建4个模块,都以platform-cip作为前缀
platform-cip-common:公共基础
platform-cip-api:API服务
platform-cip-message:消息服务
platform-cip-manage:平台管理
迁移common模块:这是个前置依赖的基础模块,迁移整合比较简单,主要工作就是改下依赖时引用的包名和路径。
拆分platform-cip模块:一分为三。
4个模块内关系为manage依赖common,api和manage相互独立,但都依赖于manage。
代码重构:将原位于api位置的实体类ApiRequest和ApiResponse,向上抽取到了common模块
这4个模块,只有manage模块有前端页面,其他三个都是类库。下面使用开发平台的低代码配置功能,来重写该模块,顺便也介绍下低代码配置功能的使用方法和注意事项。
先来回顾下整体框架与步骤,如下图所示。
接下来就具体来说说具体步骤和注意事项。
属性 | 说明 |
---|---|
应用 | 模块隶属于哪个应用,考虑到应用数量有限,属性也较少,没新建实体,使用数据字典来做一个简易化管理 |
名称 | 模块中文名称,没啥好说的 |
编码 | 模块编码,关键属性,用做唯一性标识,同时也是前端的目录名和后端模块的包名 |
缩略码 | 模块的缩略码,用于该模块库表的前缀 |
包路径 | 模块所处的包路径 |
排序 | 用来排序,下文不再重复列出 |
备注 | 就是备注,下文不再重复列出 |
上面这个例子中,因为cip本身就是缩写了,体现不出编码和缩略码的差别来。
再举一个例子,比如系统管理模块,编码是system,缩略码是sys,编码system用于前端目录名和后端的包名,缩略码sys用于该模块库表的命名前缀。
创建模块过程中,发现原来重构的manage模块的包路径没有遵循低代码配置的规范,包路径多了一段manage出来。这个简单,重构即可,把包路径manage去除,模块名保持manage不变,接口平台拆出来的4个模块,实际只有manage模块有前端功能对应,其他三个模块都是类库,所以将其视为接口平台主体也名副其实。
先选一个简单的实体来做实例。
接口平台首先需要维护对接的应用数据,这里就以应用这个实体为例。
属性 | 说明 |
---|---|
模块 | 实体隶属的模块,从上面第1步配置的数据列表中选择 |
名称 | 实体中文名称 |
编码 | 实体的英文编码,复用,作为后端实体类名、库表名 |
作者 | 用于标注实体的开发人员,会生成代码类注释中@author属性 |
开发平台内置了处理逻辑,在保存实体的时候,会自动创建一个同名的实体模型,并将其自动设置为主模型,减少重复性工作,提升开发效率。
点击保存按钮,返回列表,点击应用这行右方的配置按钮,进入实体配置页面,如下:
左侧是导航,分为两块,一是数据模型,二是视图。
属性 | 说明 |
---|---|
父模型 | 通过继承理念实现模型的复用与扩展,预置了业务模型,包含了标识、创建人、创建时间、修改人,修改时间、逻辑删除标志位、版本号(乐观锁控制),继承该模型将自动具备这些公用属性,可扩展 |
名称 | 中文名称 |
编码 | 英文编码,复用,作为库表名称(实际是库表名称的后半段,前面会加模块缩略码,避免出现不同模块下存在同名实体导致库表名重复问题) |
是否主模型 | 每个实体,下面可能有多个模型,需要标记一个主模型,作为主体,如销售订单实体,是由订单和订单明细两组成,这时候,将订单标记为主体 |
是否自关联 | 部分实体是自关联关系,如组织机构,标记自关联后,代码会在代码生成中进行额外处理,如在controller中增加获取树状结构数据的接口。 |
行记录上点击“配置属性”按钮,打开模型属性配置功能,如下:
点击新增按钮,创建新属性:
属性 | 说明 |
---|---|
名称 | 属性中文描述 |
编码 | 属性英文编码,对应java实体类中的属性,遵循小驼峰命名规范,平台依据该属性生成数据库字段名,驼峰命名风格自动转换为蛇形风格(全部小写,单词间使用下划线分隔) |
数据类型 | 属性的数据类型,包括基本类型(如文本、整形、长整型、浮点数、日期时间等)和复杂类型(如数据字典、实体),可扩展 |
控件类型 | 属性的默认展示控件,随数据类型自动变化,如文本,对应普通文本、长文本和富文本。 |
最大长度 | 属性长度设定,对应库表字段长度设置。 |
默认值 | 默认值填充,新建实体时,服务层会自动读取配置,设置属性对应的默认值。 |
是否可为空 | 属性是否允许为空,如不能为空,生成vo对象时,会自动添加验证注解@NotBlank。 |
是否唯一 | 值是否唯一,如唯一,生成服务时,会在创建或修改前,自动生成数据验证逻辑。 |
唯一性参照 | 保持为空进行全局唯一验证,可选择本实体模型其他属性,代表该属性值下唯一,通常用于父子类型数据结构下,同一父级下不能重复。 |
是否主属性 | 标记是否为主属性,该属性视为实体的主要显示属性,当该实体用于其他实体关联时,将该属性作为显示值 |
是否上级属性 | 用于标记该属性是否关联到上级 |
这里的属性,有些看上去跟模型属性无关,比如控件类型,显示格式等,放到视图配置类更合适。之所以放到实体模型属性这里,是从开发效率的角度考虑。同一模型,会配置多个视图,多次使用属性,将属性的默认显示放到实体属性里配置后,简化视图环节配置,避免重复配置,提升效率。
同理,创建其他属性。
当数据类型选择数据字典时,会自动出现字典类型选择控件,选择系统中设置的数据字典。
控件类型也会出现下拉列表和单选按钮组,通常字典项少的情况下2-3项,使用单选按钮组,操作简便,显示直观,如字典项多,则会占用大量页面显示面积,这时候,使用下拉列表更佳。
字典类型选中后,默认值也会自动加载,可根据实际情况选择是否需要设置默认值,以及将哪个字典项作为默认值。
今天先到这,视图部分超级复杂,留待下篇专题说明。
平台名称:一二三开发平台
简介: 企业级通用开发平台
设计资料:csdn专栏
开源地址:Gitee
开源协议:MIT
欢迎收藏、点赞、评论,你的支持是我前行的动力。