关于java:JeecgBoot关于-jeecgboot-的项目理解使用心得和改进建议

32次阅读

共计 5564 个字符，预计需要花费 14 分钟才能阅读完成。

工欲善其事，必先利其器。

脚手架选型

一年前，我接到 为团队落地一个疾速开发脚手架 的工作。

在月底这节骨眼上，工夫紧，工作急，有想本人撸一个脚手架的人都连忙把这想法收起来吧！这劳民又伤身的事咱必定是不能干的！

于是，我将眼光放在了 Gitee Star比拟靠前的开源我的项目上，这是过后调研的数据 Java Web 开发脚手架调研。

其中 MCMS、lenosp、bootdo 等我的项目，咱们甚至曾经有过我的项目落地教训，但最终咱们还是抉择了 jeecg-boot，抉择它的理由咱们有这几点：

  • [x] 前后拆散架构

    1. 过后咱们正在推前端工程化，前后拆散的工作模式是咱们团队的趋势

  • [x] 热门技术栈

    1. 后端同学应用 Spring Boot + Mybatis Plus，能更专一了解需要与业务逻辑
    2. 前端同学应用Vue + Ant Design Vue，既能疾速开发业务，还有工夫对页面性能优化做钻研
    3. 设计同学应用 Ant Design 组件库设计资源，对立了设计格调

  • [x] 基于角色的访问控制体系

    1. 合乎公司以后业务场景

  • [x] 欠缺的开发文档

    1. 开发文档清晰且具体，有教训的同学必定晓得保护一份欠缺的开发文档往往比写这个我的项目破费的工夫和精力还要多。
    2. 除了文档，社区还提供了视频教学，真的是贴心到了极致

  • [x] 沉闷的社区生态

    1. github issue 1300+
    2. jeecg 开源社区会员20000+
    3. 沉闷的社群交换

正是基于这些点，咱们抉择置信 jeecg-boot！<img src=”https://img-blog.csdnimg.cn/20200827115123583.png” width=”100px”/>

通过一年多，咱们见证了 jeecg-boot 在 github 从 star 2000+ 到当初的 star 14.7k，

而咱们团队也曾经有 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 的存储做了一些革新。

计划一：

  1. redis 中 token 的 key 不应用 username_token的模式，应用 username_UUID。
  2. 在登录接口中，不将 jwt 生成的 token 间接返回给前端，而是返回 UUID。
  3. 调整 ShiroRealm#doGetAuthenticationInfo逻辑，先应用 token 从 redis 获取 jwt token。
  4. 从 request 中获取 token 并应用 JwtUtil.getUsername(token)之前须要先从 redis 获取 jwt token。

计划二：

当然，还能够将 jwt token 进行加密，向前端返回加密后的 token，而后端只需减少一个对 被加密的 token进行 解密 的过滤器。

既可满足不将 jwt token 返回给前端，又不会对原有逻辑进行调整，满足 开闭准则。

对于防暴力破解

  • 【倡议】减少账户锁定策略

这也是安全部门同学找开发同学谈过话的案例!<img src=”https://img-blog.csdnimg.cn/20200827114603322.png” width=”50px”/>

咱们的实际计划：

应用 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 极不敌对。

咱们的实际计划：

  1. .env
  2. .env.development
  3. .env.production
  4. .env.test
  5. …

分环境提供配置，并在 package.json 减少相应打包脚本，进步部署效率。

相似于后端我的项目中的：

application.yml
application-dev.yml
application-prod.yml
application-test.yml

对于加强 JeecgListMixin.js

  • 【倡议】围绕 JeecgListMixin 向下提供一些勾子函数

    咱们能够看到 initDictConfig 是一个空办法，它就是一个勾子函数，子组件如果重写了该办法，则会在执行 created 生命周期函数 时，执行子组件中重写的逻辑。

    所以，咱们能够向 JeecgListMixin 的赋能更多勾子函数，满足更多场景，进步灵活性，进步开发效率。

咱们的实际计划：

// created 生命周期函数中执行 利用场景：加载异步词典项等
initDictConfig() {} 

// 搜寻之前执行 利用场景：对 queryParam 对象内的数据，做一些数据转换工作等
beforeSearch() {}

// 重置之前执行 利用场景：重置一些没有绑定在 queryParam 对象内的数据等
beforeReset() {}

// loadData 加载数据胜利之后执行 利用场景：须要在该机会下做一些数据的转换工作等
afterLoadDataSuccess() {}

// 在 loadData 内执行 利用场景：自定义数据加载逻辑
// 执行 loadData 时，会先判断是否重写了 customLoadData 办法
customLoadData() {}

对于页面性能的优化

  • 【倡议】路由懒加载
    须要留神应用路由懒加载后所带来的问题，即 刷新时会触发两次路由守卫的 beforeEach 函数
  • 【倡议】对体积较大的第三方资源拆包，或应用 CDN 引入

以后 jeecg-boot 2.2.1 是一次性加载所有资源，无论是开发还是生产阶段都是不利的！
对于开发阶段，开发同学每次刷新页面须要期待 3 ~ 4 秒，
对于生产阶段，就会波及到 首屏加载 这个指标的考验。

对资源做 按需加载 / 缩减资源体积 能极大的优化加载性能，也是一件很有意义的事。

咱们能够对 jeecg-boot 前端做的一些优化：

  1. 路由懒加载 component:() => import(/* webpackChunkName: "component" */ component.vue)
  2. 依据环境须要，应用 splitChunks 对依赖的第三方资源拆包

当然，还有更多 jeecg-boot 用户能够做的优化

  1. 文件内联（缩小申请数）
  2. 摇树优化（用不到的办法或者模块就不打包）
  3. gzip 压缩
  4. CDN 减速

对于减少 ModalMixin.js

在业务开发过程中，一个页面可能有很多 Modal / Drwaer，就须要咱们加一些响应式变量和办法去管制这些Modal / Drawer 的 显示 / 敞开，而这些工作往往都是反复的。

那么，咱们能不能形象一下这些反复的工作，将更多的精力放在组件的逻辑下来呢？

咱们的实际计划：

  1. Modal / Drawer 的父组件引入 @/mixins/ModalParentMixin，并在mounted 生命周期函数中应用 register 办法对 ref 的值进行注册

    <template>
 <div>
   <a-button type="primary" @click="showModal('addModal')"> 新增 </a-button>
   <a-button type="primary" @click="showModal('editModal')"> 编辑 </a-button>
   <a-button type="primary" @click="showModal('detailModal')"> 详情 </a-button>
   
   <!-- 新增 -->
   <modal-add  ref="addModal" @ok="searchReset"/>
   
   <!-- 编辑 -->
   <modal-edit  ref="editModal" @ok="searchReset"/>
   
   <!-- 详情 --> 
   <!-- 条件渲染，将 v -if="isShow('detailModal')" @close="closeModal" 一起应用即可 -->
   <modal-detail  ref="detailModal" @ok="searchReset" v-if="isShow('detailModal')" @close="closeModal"/>
 </div>
</template>

<script>
 import ModalParentMixin from '@/mixins/ModalParentMixin'

 export default {mixins: [ ModalParentMixin],
   mounted() {
     // 注册以后页面有哪些 modal
     this.register(['addModal', 'editModal', 'detailModal'])
   },
 }
</script>
  2. 在 Modal / Drawer 组件中引入@/mixins/ModalMixin

当初咱们管制页面上所有的 Modal / Drawer 是不是要轻松很多了呢？

再也不必申明各种不同的 xxxVisible来管制这些子组件的 显示 / 敞开。

对于修复 Ant Table 的 BUG

这个本应该去 Ant Design Vue 提 issue 的，然而跟了好几个版本之后，他们并没有做修复，失去的答案仿佛是：设计如此！

既然这样，咱们就本人来做一些解决，去躲避掉这个 BUG。

  • 复现步骤
    删除数据前 {total: 11, current: 2, pageSize: 10}。
    删除数据后 {total: 10, current: 2, pageSize: 10}，显示 暂无数据。

  • 修复
    在JeecgListMixin.js的 handleDelete、batchDel 等办法，在操作胜利后，对 current 进行从新计算。
  • 修复后成果
    删除数据前 {total: 11, current: 2, pageSize: 10}。
    删除数据后 {total: 10, current: 1, pageSize: 10}，失常显示第一页的数据。

其余

对于更新打算

  • 【倡议】减少 更新打算 菜单

能不便大家理解到 JEECG 团队 对新版本的迭代方向，减少用户粘度。

对于这个倡议曾经有 issue，置信在近期内就会看到这个菜单！

对于平滑降级

很多社区的敌人都有反馈这个问题。的确，当咱们的业务代码与 jeecg-boot 的源码交融在一起的时候，做版本升级是比拟头疼的。
特地是大版本的降级，除了源码的变动，可能还有数据库表的变更，降级会不会对咱们的业务产生影响，谁也说不清楚！

咱们的实际计划：

依赖 jeecg-spring-boot-starter，解决业务代码与 jeecg-boot 源码交融的在一起的困境。

  • 适用人群

    • 疾速开发人群
    • 不需对 jeecg-boot 的源代码进行改变的人群
    • 只需对 jeecg-boot 配置项进行调整即可满足开发的人群

有趣味的同学，能够去 github 理解它 https://github.com/tanpenggood/jeecg-spring-boot-starter。

总结

  1. jeecg-boot 显著的进步了咱们团队的开发效率。
  2. jeecg-boot 全套技术栈合乎以后技术趋势，学习文档欠缺，是一个十分值得大家学习的开源我的项目。
  3. jeecg-boot 社区沉闷，碰到问题基本上都能及时解决，有价值的问题最好再去 github 提 issue。

最初，心愿 jeecg-boot 的代码品质更加优良，心愿 jeecg-boot 成为 2020 最最最最受欢迎的开源我的项目！

正文完
java
发表至： java
2020-08-27
 0
replace java.lang.String.equals by Xbootclasspath
想面试阿里腾讯这些大厂看完此文你的成功率能达到-90
关于java:k8s-配置-Secret-集成Harbor
Java程序到底是如何执行的