MyBatis-Plus代码生成器禁用Service与Controller生成的解决方案

MyBatis-Plus作为一款优秀的ORM框架，其代码生成器功能广受开发者欢迎。但在实际使用过程中，部分开发者遇到了无法禁用Service和Controller层代码生成的问题。本文将深入分析这一问题的根源，并提供完整的解决方案。

问题背景

在使用MyBatis-Plus的FastAutoGenerator进行代码生成时，即使通过.strategyConfig()方法显式调用了.serviceBuilder().disable()和.controllerBuilder().disable()，系统仍然会生成Service和Controller层的代码文件。

问题分析

经过深入源码分析，发现问题主要源于两个方面的设计：

1. 默认值初始化机制：PackageConfig会在getPackageInfo()方法中自动初始化所有包路径的默认值，包括Service和Controller的包路径。

2. 生成条件判断逻辑：在AbstractTemplateEngine中，Service和Controller的生成判断条件过于宽松，即使禁用了生成，由于默认值的存在，判断条件仍然会被满足。

具体表现为：

• 在outputService方法中，判断条件为：service.isGenerateServiceImpl() && StringUtils.isNotBlank(tableInfo.getServiceImplName()) && StringUtils.isNotBlank(serviceImplPath)
• 由于PackageConfig默认初始化了这些值，导致条件始终为true

解决方案

针对这一问题，MyBatis-Plus团队已经在最新版本中进行了修复。开发者可以通过以下方式解决：

1. 升级版本：使用最新快照版本或等待正式版发布

2. 临时解决方案：在现有版本中，可以通过自定义模板引擎的方式绕过这一问题

.templateEngine(new FreemarkerTemplateEngine() {
    @Override
    public void outputService(TableInfo tableInfo, Map<String, Object> objectMap) {
        // 自定义Service生成逻辑
        if (strategyConfig.getService().isGenerate()) {
            super.outputService(tableInfo, objectMap);
        }
    }
    
    @Override
    public void outputController(TableInfo tableInfo, Map<String, Object> objectMap) {
        // 自定义Controller生成逻辑
        if (strategyConfig.getController().isGenerate()) {
            super.outputController(tableInfo, objectMap);
        }
    }
})

最佳实践

在使用代码生成器时，建议：

1. 明确指定所有需要生成的层，避免依赖默认行为
2. 对于不需要生成的层，除了调用disable()方法外，还可以显式设置对应的包路径为空
3. 定期关注框架更新，及时获取最新的功能和修复

总结

MyBatis-Plus的代码生成器功能强大，但在某些特定场景下可能存在一些边界条件问题。理解其内部工作机制有助于开发者更好地利用这一工具，提高开发效率。对于本文讨论的问题，开发者可以选择升级版本或采用临时解决方案，根据项目实际情况做出最佳选择。