当前位置:   article > 正文

企业级通用低代码开发平台——一二三应用开发平台发布4.2开源版本,回顾与展望_一二三平台

一二三平台

背景

今年三月初,确定了自己将来很长一段时间要做的事情,再启程,从头开始,研发一套应用开发平台,完全开源,详见https://blog.csdn.net/seawaving/article/details/129334330

从头开始,不是从零开始,大量的技术选型工作,平台设计与实现工作,都已实现,需要的大多是迁移和优化。

用了四个月的时间,基本完成了多年来设计与实现的平台功能迁移,正式发布4.2版本。
今天来做一个回顾和总结,说一说都做了哪些,以及未来的展望,规划后面要做哪些。

先放一张整体架构图
1.png

后端模块

后端做的主要工作是模块化重构,重构过程中不可避免会进行架构的调整与优化,比如某些功能需要下沉到底层公共基础模块,某些功能需要拆分为更小的颗粒度来提升复用。
到目前为止,整个工程项目,后端共计16个模块,架构图和依赖关系如下图所示:

这16个模块分成三类,一类是平台内核模块,命名规则是platform+模块功能名称,图中用蓝色标示;一类是能力扩展模块,命名规则是platform-boot-starter+模块功能名称,图中用绿色标示;剩下的一类是接口平台,命名规则是cip+模块功能名称,图中用紫色标示,相对平台独立,但又作为平台的重要组成部分。

下面来具体说一说各模块的职责以及包含的功能。

平台内核模块

platform-common作为公用基础模块,主要包括工具类、公用注解、公共父类、公共常量、公共枚举值,与前端UI交互定义的vo类,该模块为最基础的模块,无前置依赖。

platform-system是平台最核心的模块,主要包括组织机构、人员、角色(用户组)、权限、日志、系统参数、模块这些实体和服务的实现,需要注意的是,权限控制、日志记录,并不是在该模块实现,而是在platform-framework平台框架中实现,该模块依赖于platform-common。

platform-framework是平台框架,负责身份认证、权限控制、全局配置、数据分页、日志处理、自动填充(创建人、创建时间、修改人、修改时间),因为身份认证、权限控制等功能,不可避免需要使用处于platform-system模块中的人员、用户组等实体和服务,因此依赖于platform-system。

platform-support是一个业务支撑模块,基于技术组件进行功能设计与封装,实现一些通用的功能设计,更方便业务逻辑的实现,提供附件管理、通知公告、内容模板(用于短信、邮件、消息)、单据流水号、门户等功能。这些支撑模块同样需要位于platform-system模块中的人员、组织机构等实体和服务,因此依赖于platform-system。

platform-entityconfig属于低代码配置范畴,定义了业务实体的元数据,通过模块、实体、模型、视图多级配置,结合模板技术,实现细粒度的代码生成控制。

platform-boot-starter:平台启动项目,整合平台基础功能,类似于spring-boot-starter,业务系统引入该包进行依赖。该模块自身没有实体与服务,而是汇总整合,把platform-framework引用进来,同时进行配置。配置分两方面,一方面是做一个配置类,加一些注解(如:@EnableRetry、@ServletComponentScan、@EnableTransactionManagement),使用开发平台实现的业务系统,就不需要在启动类上重复添加这些注解;另一方面,是位于yml配置文件中的配置信息,也分为两部分,一部分是三方组件自身的,如数据源、连接池、redis、quartz、logback,另一方面是自定义的系统参数,如用户默认密码、导出excel数据的批次最大行数量。

platform-boot-starter-demo:示例项目,实际是模拟业务系统如何使用开发平台,用于平台自身功能开发与调试。

能力扩展模块

绿色标示的四个模块,比较好理解,通常是对第三方组件的封装与整合,依赖于公共基础模块platform-common,这些模块可以不断扩展的,业务系统按需引入即可,这样就实现了核心模块必选、扩展模块可选的目的。
platform-boot-starter-mail:邮件,集成springmail组件,实现邮件的发送功能封装
platform-boot-starter-oss: 对象存储,用于文件存储封装,底层可基于多种模式,如本地磁盘、对象存储系统等
platform-boot-starter-scheduler:任务调度,集成quartz组件,实现任务调度可视化配置
platform-boot-starter-notification:消息通知,基于netty实现的websocket,用于系统内置消息

对于扩展模块,平台的核心模块实际也可能会用到,例如platform-support中的附件功能,就会用到platform-boot-starter-oss;platform-system中的自动解锁用户功能,就会用到platform-boot-starter-scheduler。

接口平台

之前开源了一套通用接口平台,详见专栏https://blog.csdn.net/seawaving/category_11610162.html
现在,将通用接口平台作为一个模块,整合到新的应用开发平台当中来,由通用接口平台统一对外暴露应用系统的API数据接口,以及推送事件消息。
之前的的通用接口平台,主要由两个模块组成,一个是platform-cip(cip是common interface platform缩写),即接口平台的主体,另外一个是platform-cip-common,被platform-cip依赖。
实际上,接口平台的主体,platform-cip,里面包含了三块内容:
1.对外提供API数据接口,提供API服务
2.基于netty的web socket服务端提供消息服务
3.平台自身基础数据的维护,如应用、API服务清单、消息服务清单、订阅等。
本次整合,不是简单的迁移,而是包括重构优化,将platform-cip进一步拆分为三个模块,一共4个模块:
platform-cip-common:公共基础
platform-cip-api:API服务
platform-cip-message:消息服务
platform-cip-manage:平台管理
4个模块内关系为manage依赖common,api和manage相互独立,但都依赖于manage。

前端升级改造

首先是vue2.x升级vue3.x,变化最大的其实是v-model进行了调整,如下:
用于自定义组件时,v-model prop 和事件默认名称已更改:

  • prop:value -> modelValue;
  • 事件:input -> update:modelValue;

几乎所有的自己封装的自定义组件,都要进行相应调整。

此外,vue3兼容了原来的选项式API,新增了组合式API。虽然组合式API更简练,可以将相关的内容集中放在一起,避免来回拖动滚动条,但实际体验不咋样,特别是一些功能组件太随意,相关内容分散到了整个文件各个地方,修改的时候反而需要通过搜索功能才能定位,个人认为不如vue2的选项式API风格,直接去固定的块里找就好了。

其次是element ui升级element plus。总体来说,这块也还好,大部分沿用了旧版本的属性、方法和事件,个别需要调整,工作量还好,印象中涉及到插槽slot的较多,不做相应调整直接就会报错无法正常显示。

最后是vue-element-admin升级vue-element-plus-admin,这块变化挺大。实际上最主要的一点是,这两个都是前端框架,跟后端整合,需要做大量改造,包括登录、获取菜单和路由、会话失效处理、自动附加token等等。
此外,框架附带了部分封装的组件,实际使用过程中发现,比element plus原生组件更好用一点,但同时封装过程中也把部分element plus原生组件的属性、事件和方法给移除掉了,从而影响到了灵活性和扩展性,因此建议慎用。

实际最麻烦的一块,是第三方组件,或者说是vue3的生态。vue3是2020年9月发布的,到现在都快三年了,第三方组件,普遍面临没支持或支持不足的局面,比较尴尬,如前端文件上传组件vue-simple-uploader、v-charts等,自己动手改造和适配难度不小,工作量很大。

未来规划

客观地说,目前开发平台已经实现了大部分常用常见功能,可以投入使用了。由于是一路狂奔模式,速度提升,时间缩短,但不可避免一些功能遗留了待办项,以及未充分测试导致存在bug,后面需要再循着功能过一遍,进行重构、测试,完善功能,输出设计。特别是低代码配置部分,需要持续完善与改进,简化配置,进一步提升开发效率。

后面几块是平台欠缺的,需要补全和完善,每一块都是硬骨头,难度和工作量都不小,做了一些简单初步的了解,具体如下:

集成图表组件

图表展现能力是平台需具备的基础能力,目前echarts是最佳选择。
在早期版本的百度图表中,不同的图表样式,需要不同的数据格式,需要进行复杂封装才能易于使用。百度官方也意识到这个问题,在echarts 4.0版本提供了dataset属性支持,提供了统一的数据格式,也曾考虑基于这一新特性将常用图表进行封装。
后来,发现了饿了么团队出品的开源组件v-charts,统一提供了一种对前后端都友好的数据格式,只需设置简单的配置项,便可轻松生成常见的图表。
但v-charts停留在了vue2.x版本,vue3.x完全没有动静。百度官方自己出了vue-echarts,待进一步做技术预研后集成。

集成工作流

2021年左右,选择了activiti的分支comunda。当时的情况是activiti主分支已落寞,在comunda和flowable这两个分支中选择了前者。集成原生工作流引擎工作量很大,当时投入了几个月,实现了主要功能,效果不是很满意。
简单看了下近况,市面上最多的依旧是基于comunda或flowable进行的二开。
看好国产自研的济南驰骋的JFlow,

表单可视化

虽然平台自身实现的低代码配置部分,可以配置生成前端vue页面,但表单客户端配置这块,对于非标准化的复杂表单,依旧有价值,特别是对于工作流流程中携带的表单的配置。市面上有些表单配置组件,如form-generator,纯前端,跟后端难以集成与整合,实用性有限。比较看好的模式是FormMaking,有接口来集成后端数据,基于vue3和element plus组件,可惜的是需要商务授权。
还有一个方向是上文提到的驰骋JFlow也附带了表单可视化设计,或许能一起解决,还省了自定义表单和流程的集成工作,待进一步了解和评估。

移动端实现

uni-app,无可争议的多端开发框架,vue开发语言和微信api的组合,巧妙而强大,生态已经做起来了。
这块技术难度一般,工作量比较大。

自定义查询

允许用户自己配置查询条件,单表查询比较容易实现,多表连接查询难度大。

实现数据权限

数据权限是一个非常复杂的问题,如何兼顾灵活性和性能的情况下落地,难度很大。目前市面上很多所谓的数据权限实际没有真正实现,要么是预设了组织机构单一维度,给角色设置只看本部门等所谓的数据权限,首先方向就错了,真正的数据权限控制,应该是给要控制的对象设置权限控制策略。
虽然业务系统对于数据权限的控制需求,或者说控制维度是多种多样的,很难标准化,但是还是有一些常用的。
首先,组织机构是最常见,使用频率最高的一个的控制维度。对于一个集团公司,北京分公司与上海分公司,业务数据在公司范围内可见;公司内部不同部门,如采购部门和销售部门,业务数据在部门内范围内可见。
其次,角色也是经常会用到的,用于跨组织机构或没有系统内部的数据从属关系,例如,公司的几个高管,每人分管几个部门,某个高管,跟分管的部门之间从系统看是没有关联的,但客观又存在业务上的需要,高管能看到自己分管的部门数据。
再次,是与当前用户相关,如要求只有发帖人才能修改帖子内容。
最后,就是跟业务实体的具体属性相关了,例如,业务类型是采购还是销售,配送方式是自提还是送到,合同金额超过100万等。
需要注意的是,以上各维度不是单选,而是存在组合情况。

此外,还需要输出平台使用手册,没有文档的平台,做得再好,也是难以熟悉和使用的。

开发平台资料

平台名称:一二三开发平台
简介: 企业级通用开发平台
设计资料:csdn专栏
开源地址:Gitee
开源协议:MIT
开源不易,欢迎收藏、点赞、评论。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小丑西瓜9/article/detail/422530
推荐阅读
相关标签
  

闽ICP备14008679号