【JeecgBoot】关于 jeecg-boot 的项目理解、使用心得和改进建议

最新推荐文章于 2024-06-18 14:55:23 发布

6个日的梦想

最新推荐文章于 2024-06-18 14:55:23 发布

阅读量2.8k

点赞数 5

分类专栏：系统架构积累文章标签：开源项目

本文链接：https://blog.csdn.net/wu6cfp38/article/details/130393372

版权

系统架构积累专栏收录该内容

13 篇文章 1 订阅

订阅专栏

最近有一些小项目，互相没有关联的，想找一个脚手架直接开发业务。

脚手架选型

自己搞，那肯定很费时间了

就去gitee,gitehub上逛开源的项目

最终我们还是选择了jeecg-boot，选择它的理由我们有这几点：

jeecg-boot: 🔥「企业级低代码平台」前后端分离架构SpringBoot 2.x，SpringCloud，Ant Design&Vue，Mybatis，Shiro，JWT。强大的代码生成器让前后端代码一键生成，无需写任何代码! 引领新的开发模式OnlineCoding->代码生成->手工MERGE，帮助Java项目解决70%重复工作，让开发更关注业务，既能快速提高效率，帮助公司节省成本，同时又不失灵活性。

前后分离架构
1. 当时我们正在推前端工程化，前后分离的工作模式是我们团队的趋势
热门技术栈
1. 后端同学使用 Spring Boot + Mybatis Plus，能更专注理解需求与业务逻辑
2. 前端同学使用Vue + Ant Design Vue，既能快速开发业务，还有时间对页面性能优化做研究
3. 设计同学使用Ant Design组件库设计资源，统一了设计风格
基于角色的访问控制体系
1. 符合公司当前业务场景
完善的开发文档
1. 开发文档清晰且详细，有经验的同学肯定知道维护一份完善的开发文档往往比写这个项目花费的时间和精力还要多。
2. 除了文档，社区还提供了视频教学，真的是贴心到了极致

活跃的社区生态（能用啥开源软件，不就是看活跃度，防止没人维护，自己人坑次坑次看源码）
1. github issue 1300+
2. jeecg开源社区会员20000+
3. 活跃的社群交流

而我们团队也已经有 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极不友好。

我们的实践方案：