最近有一些小项目,互相没有关联的,想找一个脚手架直接开发业务。
脚手架选型
自己搞,那肯定很费时间了
就去gitee,gitehub上逛开源的项目
最终我们还是选择了jeecg-boot,选择它的理由我们有这几点:
-
前后分离架构
- 当时我们正在推前端工程化,前后分离的工作模式是我们团队的趋势
-
热门技术栈
- 后端同学使用
Spring Boot + Mybatis Plus
,能更专注理解需求与业务逻辑 - 前端同学使用
Vue + Ant Design Vue
,既能快速开发业务,还有时间对页面性能优化做研究 - 设计同学使用
Ant Design
组件库设计资源,统一了设计风格
- 后端同学使用
-
基于角色的访问控制体系
- 符合公司当前业务场景
-
完善的开发文档
-
活跃的社区生态(能用啥开源软件,不就是看活跃度,防止没人维护,自己人坑次坑次看源码)
- github issue
1300+
- jeecg开源社区会员
20000+
- 活跃的社群交流
- github issue
而我们团队也已经有 5 个服务是基于 jeecg-boot 2.0.0 进行开发,并有 4 个服务已投入生产使用。
改进建议
后端
关于分层领域模型
- 【建议】将 分层领域模型 落地
相比我们使用的 2.0.0 版本,jeecg-boot 2.2.1
在功能上已经非常完善,且已经形成了稳定的代码风格,在代码分层的工作上也细化了很多。
但是,在分层领域模型
方面,始终是使用Entity
贯穿各层,如果能将分层领域模型
落地,jeecg-boot 一定会更加优秀。
我们在分层领域模型规约的一些实践: 遵循 JAVA开发手册
# 对象模型
Model (接口入参 表单验证 swagger注解)
VO (返回页面对象) View Object
BO (业务层对象)
DO (数据库返回结果集)
DTO (远程调用传输对象)
实体类 (与数据表一一对应)
# 接口入参接收对象:XXXModel
【推荐】不包含`id、updateBy、updateTime、createBy、createTime`等属性,通过sql拦截注入这一系列字段
【推荐】必传字段校验
【推荐】字段长度校验
【推荐】格式校验
【推荐】时间格式转换 `@DateTimeFormat` (入参格式化,将字符串时间格式化为Date对象)
# 接口返回值:XXXVO
【强制】不包含敏感字段(手机号、密码、邮箱、身份证号)
【强制】包含敏感字段时对数据加密
【推荐】使用`@JsonView`注解控制返回值的字段可见性
【推荐】字典字段转换 如,`@Dict(dicCode = "sex")`
【推荐】时间格式转换 `@JsonFormat` (出参格式化,将Date对象时间格式化为字符串)
安全性方面
关于签发给前端的 token
- 【建议】不将 jwt 生成的 token 直接返回给前端
这里之所以有这个建议,是因为我们安全部门的同学找了开发同学好几次麻烦,最后我们将 token 的存储做了一些改造。
方案一:
- redis 中 token 的 key 不使用
username_token
的形式,使用username_UUID
。 - 在登录接口中,不将 jwt 生成的 token 直接返回给前端,而是返回 UUID 。
- 调整
ShiroRealm#doGetAuthenticationInfo
逻辑,先使用 token 从 redis 获取 jwt token 。 - 从 request 中获取 token 并使用
JwtUtil.getUsername(token)
之前需要先从 redis 获取 jwt token 。
方案二:
当然,还可以将 jwt token 进行加密,向前端返回加密后的 token,而后端只需增加一个对被加密的token
进行解密
的过滤器。
既可满足不将 jwt token 返回给前端,又不会对原有逻辑进行调整,满足开闭原则
。
关于防暴力破解
- 【建议】增加账户锁定策略
我们的实践方案:
使用 redis 对单位时间内(我们是 5 分钟)的用户登录失败次数进行计数。
失败次数达到 5 次后,将对该账户进行冻结(5 分钟),5 分钟后 redis key 过期,该用户即可正常登录。
关于 jeecg 配置
- 增加
JeecgPorperties.java
对前缀为jeecg
的配置进行管理,避免使用@Value
获取属性值的行为。 - 引入
spring-boot-configuration-processor
依赖,为已声明的配置项增加提示。
前端
关于环境配置文件
- 【建议】引入
.env.*
配置文件,将配置与环境隔离
目前 jeecg-boot 的前端,一直使用的是 window._CONFIG
来挂载相关全局变量,它有一个缺点就是没有将配置与环境隔离
。
比如:
在开发环境下window._CONFIG['domianURL'] = 'http://127.0.0.1:8080/jeecg-boot'
在测试环境下window._CONFIG['domianURL'] = 'http://test.product.com:8080/jeecg-boot'
在生产环境下window._CONFIG['domianURL'] = 'http://prod.product.com:8080/jeecg-boot'
打包不同的环境,都需要人为的去改动这些配置,对CI/CD
极不友好。
我们的实践方案:
- .env
- .env.development
- .env.production
- .env.test
- ...
分环境提供配置,并在package.json
增加相应打包脚本,提高部署效率。
类似于后端项目中的:
application.yml
application-dev.yml
application-prod.yml
application-test.yml
还有一个开源脚手架若依:也是一个不错的选择
RuoYi-Cloud: 🎉 基于Spring Boot、Spring Cloud & Alibaba的分布式微服务架构权限管理系统,同时提供了 Vue3 的版本
开源的不但有单体的,还有微服务架构的,可以按照自己的项目,需求做选择。
小朋友才做选择,都要学,哈哈。jeecg-boot可不只是脚手架,还有很多低代码的功能,甚至出了零代码的项目,还是很值得学习的。