工欲善其事，必先利其器。脚手架选择一年前，我接到了为团队落地快速开发脚手架的任务。月末关键时刻，时间紧迫，任务紧迫。想自己搭脚手架的人赶紧收起这个念头吧！这种又费力又伤人的事情，我们是绝对不能做的！于是，我把目光投向了GiteeStar的顶级开源项目，也就是当时调查的数据。JavaWeb开发脚手架研究。其中MCMS、lenosp、bootdo等项目，我们甚至有过项目实施经验，但最终还是选择了jeecg-boot。我们选择它的原因有以下几点：[x]前后端分离架构当时我们在推前端项目我们团队的趋势是前后端的现代化和分离。[x]热门技术栈后端同学使用SpringBoot+MybatisPlus，可以更专注于理解需求和业务逻辑。前端同学用Vue+AntDesignVue，可以快速开发业务，还有时间做页面性能优化的研究和设计。同学们使用AntDesign组件库来设计资源，统一了设计风格[x]基于角色的访问控制体系，符合公司目前的业务场景[x]完善的开发文档开发文档清晰详细，有经验??的同学要知道，维护一个完整的开发文档往往比写这个项目要花费更多的时间和精力。除了文档，社区还提供视频教学，真是贴心到极致[x]活跃的社区生态github问题1300+jeecg开源社区成员20000+活跃的社区交流就是基于这几点，我们选择相信jeecg-引导！时隔一年多，我们见证了jeecg-boot在github上从star2000+到现在的star14.7k，我们团队已经基于jeecg-boot2.0.0开发了5个服务，4个服务已经上线。后端层级领域模型的改进建议[建议]实现层级领域模型jeecg-boot2.2.1相对于我们使用的2.0.0版本，功能已经非常完善，并且形成了稳定的代码风格。代码分层方面的工作也细化了很多。但是，对于分层领域模型而言，总是使用Entity来贯穿每一层。如果能实现分层领域模型，jeecg-boot肯定会更好。我们在分层领域模型规范中的一些做法：遵循JAVA开发手册#对象模型Model（接口输入参数表单验证swagger注解）VO（返回页面对象）ViewObjectBO（业务层对象）DO（数据库返回结果集）DTO（远程调用传输对象）实体类（与数据表一一对应）#接口入参接收对象：XXXModel【推荐】不包含`id、updateBy、updateTime、createBy、createTime`等属性，注入这个通过sql拦截series字段[推荐]必填字段验证[推荐]字段长度验证[推荐]格式验证[推荐]时间格式转换@DateTimeFormat(入参格式，将字符串时间格式化成Date对象)#接口返回取值：XXXVO【强制】不包含敏感字段（手机号、密码、邮箱、身份证号）【强制】敏感字段加密included[推荐]使用`@JsonView`注解控制返回值的字段可见性[推荐]】字典字段转换如`@Dict(dicCode="sex")`[推荐]时间格式转换`@JsonFormat`(exportparameterformatting,formatDateobjecttimeintoastring）关于发给前端的token【建议】不要直接将jwt生成的token返回给前端。提出这个建议的原因是我们安全部的同学多次找开发同学的麻烦，最后我们对token存储做了一些修改。方案一：redis中token的key不使用username_token的形式，而是使用username_UUID。在登录界面，jwt生成的token并没有直接返回给前端，而是返回了UUID。调整ShiroRealm#doGetAuthenticationInfo逻辑，首先使用token从redis获取jwttoken。在从请求中获取令牌并使用JwtUtil.getUsername(token)之前，您需要先从redis中获取jwt令牌。方案二：当然也可以对jwttoken进行加密，将加密后的token返回给前端，后端只需要添加一个过滤器即可对加密后的token进行解密。可以满足不把jwttoken返回给前端，不需要调整原有逻辑，满足开闭原则。关于反暴力破解【建议】增加账号锁定策略这也是安全系同学跟开发同学聊的一个案例！我们的实用方案：使用redis统计单位时间内用户登录失败次数（我们是5分钟).失败次数达到5次后，账户将被冻结（5分钟），5分钟后rediskey失效，用户可以正常登录。关于jeecg配置，添加JeecgPorperties.java管理jeecg前缀的配置，避免使用@Value获取属性值的行为。引入spring-boot-configuration-processor依赖，为声明的配置项添加提示。前端环境配置文件[建议]引入.env.*配置文件，将配置与环境隔离。目前jeecg-boot的前端一直在使用window._CONFIG挂载相关的全局变量。它有一个缺点就是没有配置与环境隔离。例如：在开发环境窗口._CONFIG['domianURL']='http://127.0.0.1:8080/jeecg-boot'在测试环境窗口._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.ymlapplication-dev.ymlapplication-prod.ymlapplication-test.yml关于增强JeecgListMixin.js[建议]围绕JeecgListMixin提供一些hook函数我们可以看到initDictConfig是一个空方法，它是一个钩子函数。如果子组件重写了该方法，则在执行创建的生命周期函数时，会执行子组件中重写的逻辑。因此，我们可以为JeecgListMixin赋能更多的钩子函数，以满足更多的场景，提高灵活性，提高开发效率。我们的实践计划：//在创建的生命周期函数中执行应用场景：加载异步字典项等initDictConfig(){}//在搜索前执行应用场景：对queryParam对象中的数据做一些数据转换工作，etc.beforeSearch(){}//执行reset前的应用场景：重置queryParam对象中未绑定的一些数据等beforeReset(){}//loadData加载数据成功后执行应用场景：需要这时候做一些数据转换Worketc.afterLoadDataSuccess(){}//执行loadData中的应用场景：自定义数据加载逻辑//执行loadData时，会先判断customLoadData方法是否被重写。懒加载需要注意路由懒加载带来的问题，即刷新时会触发两次路由守卫的beforeEach函数。[建议]解压大型第三方资源，或者使用CDN导入目前的jeecg-boot2.2.1是一次加载所有资源，对开发和生产阶段都不利！对于开发阶段，开发者每次刷新页面需要等待3~4秒。生产阶段会涉及到首屏加载指示器的测试。按需加载/缩减资源，可以大大优化加载性能，也是非常有意义的。我们可以在jeecg-boot的前端做一些优化：Lazyroutingcomponent:()=>import(/*webpackChunkName:"component"*/component.vue)根据环境需要，使用splitChunks解包依赖第三方资源当然jeecg-boot用户可以做的优化还有很多。文件内联（减少请求数）Treeshaking优化（未使用的方法或模块不打包）gzip压缩CDN加速关于在业务开发过程中加入ModalMixin.js中，一个页面可能有很多Modals/Drawers，所以我们需要添加一些响应变量和方法来控制这些Modals/Drawers的显示/关闭，并且这些任务经常重复。那么，我们能否将这些重复性的工作抽象出来，更专注于组件的逻辑呢？我们的实践方案：Modal/Drawer的父组件引入@/mixins/ModalParentMixin，在挂载的生命周期函数在Modal/Drawer组件中引入@/mixins/ModalMixin现在我们控制页面上所有的Modal/Drawer是容易多了？不再需要声明各种xxxVisible来控制这些子组件的显示/关闭。关于修复AntTable的BUG，这个应该是在AntDesignVue中提出来的，但是后来几个版本都没有修复，得到的答案似乎是：设计使然！在这种情况下，我们会自己做一些处理来避免这个BUG。在删除数据之前重现{total:11,current:2,pageSize:10}的步骤。删除数据{total:10,current:2,pageSize:10}后，显示还没有数据。修复JeecgListMixin.js中的handleDelete、batchDel等方法，运行成功后重新计算当前。修复后删除数据前的效果为{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。总结jeecg-boot极大的提升了我们团队的开发效率。全套jeecg-boot技术栈符合当前技术趋势，学习文档齐全。是一个值得学习的开源项目。jeecg-boot社区活跃，基本能及时解决问题。有价值的问题最好在github上提issue。最后希望jeecg-boot的代码质量越来越好，希望jeecg-boot成为2020年最火的开源项目！
