MyBatis-Plus代码生成器禁用Service和Controller生成问题分析

MyBatis-Plus代码生成器禁用Service和Controller生成问题分析

【免费下载链接】mybatis-plus mybatis 增强工具包，简化 CRUD 操作。 文档 http://baomidou.com 低代码组件库 http://aizuda.com 项目地址: https://gitcode.com/baomidou/mybatis-plus

问题背景

在使用MyBatis-Plus的FastAutoGenerator进行代码生成时，开发者发现即使通过.serviceBuilder().disable()和.controllerBuilder().disable()配置尝试禁用Service和Controller层的生成，代码生成器仍然会生成这些文件。

问题根源分析

经过深入分析，这个问题主要源于MyBatis-Plus代码生成器的两个设计特点：

1. PackageConfig的默认初始化行为：PackageConfig类在获取包信息时会默认初始化所有层级的包路径，包括Service和Controller层。即使开发者没有显式配置这些路径，系统也会自动填充默认值。

2. 模板引擎的条件判断逻辑：在AbstractTemplateEngine中，判断是否生成Service实现类的逻辑存在缺陷。它检查三个条件：

   • service.isGenerateServiceImpl()
   • StringUtils.isNotBlank(tableInfo.getServiceImplName())
   • StringUtils.isNotBlank(serviceImplPath))

由于PackageConfig的默认初始化行为，后两个条件总是为true，导致即使禁用了Service生成，仍然会生成相关文件。

解决方案

对于当前版本(3.5.6)的用户，可以通过以下临时解决方案：

1. 显式设置空路径：

.packageConfig(packageConfig -> packageConfig
    .service("")  // 显式设置为空
    .serviceImpl("")
    .controller("")
)

2. 自定义模板引擎：继承现有模板引擎并重写相关方法，修改生成逻辑。

3. 等待官方修复：该问题已在后续版本中得到修复，开发者可以关注官方更新。

技术原理深入

MyBatis-Plus代码生成器的设计采用了"约定优于配置"的原则，这导致了一些默认行为：

• 包路径自动推导：系统会根据父包名自动推导各层级的包路径
• 文件生成条件判断：生成决策基于多个条件的组合，包括配置开关和路径非空检查
• 模板渲染机制：使用Velocity等模板引擎根据模板文件和上下文数据生成代码

这种设计虽然提高了易用性，但在需要精细控制时可能会带来一些限制。

最佳实践建议

1. 明确配置所有路径：即使不需要某些层级的代码，也最好显式配置其路径
2. 版本选择：考虑使用已修复该问题的较新版本
3. 自定义模板：对于复杂需求，可以自定义模板文件以获得更精确的控制
4. 代码审查：生成代码后应进行人工审查，确保符合项目规范

总结

MyBatis-Plus的代码生成器在提供便利的同时，也存在一些需要开发者注意的行为特性。理解其内部工作机制有助于更好地利用这一工具，避免意外行为。对于需要精确控制生成内容的场景，建议结合显式配置和自定义模板来实现需求。

【免费下载链接】mybatis-plus mybatis 增强工具包，简化 CRUD 操作。 文档 http://baomidou.com 低代码组件库 http://aizuda.com 项目地址: https://gitcode.com/baomidou/mybatis-plus