工欲善其事，必先利其器。
一年前，我接到的任务。
在月底这节骨眼上，时间紧，任务急，有想自己撸一个脚手架的人都赶紧把这想法收起来吧！这劳民又伤身的事咱肯定是不能干的！
于是，我将目光放在了 Gitee 比较靠前的开源项目上，这是当时调研的数据 Java Web 开发脚手架调研。
其中MCMS、lenosp、bootdo等项目，我们甚至已经有过项目落地经验，但最终我们还是选择了jeecg-boot，选择它的理由我们有这几点：
-
前后分离架构
- 当时我们正在推前端工程化，前后分离的工作模式是我们团队的趋势
-
热门技术栈
- 后端同学使用 ，能更专注理解需求与业务逻辑
- 前端同学使用，既能快速开发业务，还有时间对页面性能优化做研究
- 设计同学使用组件库设计资源，统一了设计风格
-
基于角色的访问控制体系
- 符合公司当前业务场景
-
完善的开发文档
- 开发文档清晰且详细，有经验的同学肯定知道维护一份完善的开发文档往往比写这个项目花费的时间和精力还要多。
- 除了文档，社区还提供了视频教学，真的是贴心到了极致
-
活跃的社区生态
- github issue
- jeecg开源社区会员
- 活跃的社群交流
经过一年多，我们见证了 jeecg-boot 在 github 从 到现在的 ，
而我们团队也已经有 5 个服务是基于 jeecg-boot 2.0.0 进行开发，并有 4 个服务已投入生产使用。
关于分层领域模型
- 【建议】将 分层领域模型 落地
相比我们使用的 2.0.0 版本， 在功能上已经非常完善，且已经形成了稳定的代码风格，在代码分层的工作上也细化了很多。
但是，在方面，始终是使用贯穿各层，如果能将落地，jeecg-boot 一定会更加优秀。
我们在分层领域模型规约的一些实践： 遵循 JAVA开发手册
关于签发给前端的 token
- 【建议】不将 jwt 生成的 token 直接返回给前端
这里之所以有这个建议，是因为我们安全部门的同学找了开发同学好几次麻烦，最后我们将 token 的存储做了一些改造。
方案一：
- redis 中 token 的 key 不使用 的形式，使用 。
- 在登录接口中，不将 jwt 生成的 token 直接返回给前端，而是返回 UUID 。
- 调整 逻辑，先使用 token 从 redis 获取 jwt token 。
- 从 request 中获取 token 并使用 之前需要先从 redis 获取 jwt token 。
方案二：
当然，还可以将 jwt token 进行加密，向前端返回加密后的 token，而后端只需增加一个对进行的过滤器。
既可满足不将 jwt token 返回给前端，又不会对原有逻辑进行调整，满足。
关于防暴力破解
- 【建议】增加账户锁定策略
我们的实践方案：
使用 redis 对单位时间内（我们是 5 分钟）的用户登录失败次数进行计数。
失败次数达到 5 次后，将对该账户进行冻结（5 分钟），5 分钟后 redis key 过期，该用户即可正常登录。
关于 jeecg 配置
- 增加对前缀为的配置进行管理，避免使用获取属性值的行为。
- 引入依赖，为已声明的配置项增加提示。
关于环境配置文件
- 【建议】引入配置文件，将配置与环境隔离
目前 jeecg-boot 的前端，一直使用的是 来挂载相关全局变量，它有一个缺点就是。
比如：
在开发环境下
在测试环境下
在生产环境下
打包不同的环境，都需要人为的去改动这些配置，对极不友好。
我们的实践方案：
- .env
- .env.development
- .env.production
- .env.test
- ...
分环境提供配置，并在增加相应打包脚本，提高部署效率。
类似于后端项目中的：
关于增强 JeecgListMixin.js
-
【建议】围绕 JeecgListMixin 向下提供一些勾子函数
我们可以看到是一个空方法，它就是一个勾子函数，子组件如果重写了该方法，则会在执行时，执行子组件中重写的逻辑。
所以，我们可以向的赋能更多勾子函数，满足更多场景，提高灵活性，提高开发效率。
我们的实践方案：
关于页面性能的优化
- 【建议】路由懒加载
需要注意使用路由懒加载后所带来的问题，即 - 【建议】对体积较大的第三方资源拆包，或使用CDN引入
当前 jeecg-boot 2.2.1 是一次性加载所有资源，无论是开发还是生产阶段都是不利的！
对于开发阶段，开发同学每次刷新页面需要等待 3 ~ 4 秒，
对于生产阶段，就会涉及到这个指标的考验。
对资源做能极大的优化加载性能，也是一件很有意义的事。
我们可以对 jeecg-boot 前端做的一些优化：
- 路由懒加载
- 根据环境需要，使用对依赖的第三方资源拆包
当然，还有更多 jeecg-boot 用户可以做的优化
- 文件内联（减少请求数）
- 摇树优化（用不到的方法或者模块就不打包）
- gzip压缩
- CDN加速
关于增加ModalMixin.js
在业务开发过程中，一个页面可能有很多，就需要我们加一些响应式变量和方法去控制这些的 显示/关闭，而这些工作往往都是重复的。
那么，我们能不能抽象一下这些重复的工作，将更多的精力放在组件的逻辑上去呢？
我们的实践方案：
- Modal / Drawer 的父组件引入 ，并在生命周期函数中使用方法对 ref 的值进行注册
- 在 Modal / Drawer 组件中引入
现在我们控制页面上所有的 Modal / Drawer 是不是要轻松很多了呢？
再也不用声明各种不同的 来控制这些子组件的。
关于修复 Ant Table 的 BUG
这个本应该去 Ant Design Vue 提 issue 的，但是跟了好几个版本之后，他们并没有做修复，得到的答案似乎是：！
既然这样，我们就自己来做一些处理，去规避掉这个 BUG。
-
修复
在的、等方法，在操作成功后，对进行重新计算。 -
修复后效果
删除数据前 。
删除数据后 ，正常显示第一页的数据。
关于更新计划
- 【建议】增加菜单
能方便大家了解到 JEECG团队 对新版本的迭代方向，增加用户粘度。
关于这个建议已经有 issue，相信在近期内就会看到这个菜单！
关于平滑升级
很多社区的朋友都有反应这个问题。确实，当我们的业务代码与 jeecg-boot 的源码融合在一起的时候，做版本升级是比较头疼的。
特别是大版本的升级，除了源码的变动，可能还有数据库表的变更，升级会不会对我们的业务产生影响，谁也说不清楚！
我们的实践方案：
依赖 jeecg-spring-boot-starter，解决业务代码与 jeecg-boot 源码融合的在一起的窘境。
- 适用人群
- 快速开发人群
- 不需对 jeecg-boot 的源代码进行改动的人群
- 只需对 jeecg-boot 配置项进行调整即可满足开发的人群
有兴趣的同学，可以去 github 了解它 https://github.com/tanpenggood/jeecg-spring-boot-starter。
- jeecg-boot 明显的提高了我们团队的开发效率。
- jeecg-boot 全套技术栈符合当前技术趋势，学习文档完善，是一个非常值得大家学习的开源项目。
- jeecg-boot 社区活跃，碰到问题基本上都能及时解决，有价值的问题最好再去 github 提 issue。