MyBatis-Plus Generator Repository层代码自动生成最佳实践

问题定位：数据访问层开发的痛点与挑战

在企业级应用开发中，数据访问层（Repository）的构建往往面临三大核心痛点：

1. 重复劳动密集：每个实体类都需要编写CRUD接口和实现类，在大型项目中动辄产生上百个重复模板代码文件
2. 架构规范难统一：不同开发者对Repository模式理解差异导致方法命名混乱，如getById()/findById()/queryById()并存
3. 维护成本高昂：数据库表结构变更时，需同步修改实体类、Mapper接口和Repository实现，容易出现遗漏

传统开发模式下，一个包含10个实体的数据访问层平均需要编写约1500行代码，其中80%为重复模板代码。这种模式不仅开发效率低下，还会因人工编写导致约15%的潜在错误率。

方案设计：基于MyBatis-Plus Generator的解决方案

需求分析：传统开发vs自动生成效率对比

开发环节	传统开发模式	自动生成方案	效率提升
接口定义	手动编写每个方法	模板化生成	90%
实现类编写	重复CRUD逻辑	继承基类+策略模式	85%
结构调整	全局替换或逐个修改	重新生成+差异化合并	70%
总计	5人天/模块	0.5人天/模块	约90%

MyBatis-Plus Generator通过代码生成器（AutoGenerator）组件，结合模板引擎和策略配置，能够完美解决上述痛点，实现Repository层的"零手工"构建。

基础版配置：快速实现Repository生成

以下基础配置可满足大多数简单项目需求，核心解决包路径重定向和命名规范统一问题：

// 解决数据源配置重复问题：集中管理数据库连接信息
DataSourceConfig dataSourceConfig = new DataSourceConfig.Builder(
    "jdbc:mysql://localhost:3306/test", 
    "root", 
    "password"
).build();

AutoGenerator generator = new AutoGenerator(dataSourceConfig);

// 解决包结构混乱问题：标准化各层包路径
generator.packageInfo(new PackageConfig.Builder()
    .parent("com.company.project")
    .entity("domain.entity")      // 实体类包
    .mapper("domain.mapper")      // Mapper接口包
    .service("domain.repository") // Repository接口包
    .serviceImpl("domain.repository.impl") // 实现类包
    .build());

// 解决命名不规范问题：统一Repository命名风格
generator.strategy(new StrategyConfig.Builder()
    .serviceBuilder()
        .convertServiceFileName(entityName -> "I" + entityName + "Repository")
        .convertServiceImplFileName(entityName -> entityName + "Repository")
    .entityBuilder()
        .enableLombok()  // 减少样板代码：自动生成getter/setter
    .build());

// 解决输出路径混乱问题：指定统一输出目录
generator.global(new GlobalConfig.Builder()
    .outputDir(System.getProperty("user.dir") + "/src/main/java")
    .author("AutoGenerator")
    .build());

generator.execute(); // 执行生成

验证要点：

• 检查生成文件的包路径是否符合domain.repository规范
• 确认接口名称是否以I为前缀且以Repository结尾
• 验证实现类是否正确继承ServiceImpl基类

进阶版配置：融入设计模式的最佳实践

针对中大型项目，需引入设计模式提升代码质量和扩展性：

// 解决接口隔离问题：基于接口隔离原则设计多层抽象
generator.strategy(new StrategyConfig.Builder()
    .serviceBuilder()
        // 依赖注入设计：通过构造函数注入Mapper
        .superServiceClass(BaseRepository.class)
        .superServiceImplClass(BaseRepositoryImpl.class)
        // 模板方法模式：定义通用查询骨架
        .methodNameConvertor(method -> {
            // 统一方法命名：将MyBatis-Plus默认方法名转换为Repository风格
            Map<String, String> methodMap = new HashMap<>();
            methodMap.put("getById", "findById");
            methodMap.put("list", "findAll");
            methodMap.put("save", "add");
            return methodMap.getOrDefault(method, method);
        })
    .entityBuilder()
        .enableTableFieldAnnotation() // 明确标识数据库字段映射关系
        .addTableFills(
            // 策略模式：自动填充创建时间和更新时间
            new Column("create_time", FieldFill.INSERT),
            new Column("update_time", FieldFill.INSERT_UPDATE)
        )
    .build());

// 解决模板定制问题：自定义Freemarker模板路径
generator.template(new TemplateConfig.Builder()
    .service("/templates/repository/service.java")
    .serviceImpl("/templates/repository/serviceImpl.java")
    .build());

验证要点：

• 检查生成的Repository接口是否继承自定义BaseRepository
• 确认方法名是否已转换为Repository风格（如findById而非getById）
• 验证实体类是否自动添加了字段填充注解

实现验证：从配置到落地的关键步骤

环境准备

# 克隆官方仓库
git clone https://gitcode.com/baomidou/mybatis-plus

# 引入Generator依赖（Maven示例）
<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-generator</artifactId>
    <version>3.5.3.1</version>
</dependency>
<dependency>
    <groupId>org.freemarker</groupId>
    <artifactId>freemarker</artifactId>
    <version>2.3.31</version>
</dependency>

基类设计示例

为实现依赖注入和模板方法模式，需提前定义基础Repository接口和实现类：

// 基础Repository接口：定义通用查询方法
public interface BaseRepository<T> {
    // 模板方法：分页查询骨架
    default Page<T> findByPage(Pageable pageable) {
        Page<T> page = new Page<>(pageable.getPageNumber(), pageable.getPageSize());
        return selectPage(page, createQueryWrapper(pageable));
    }
    
    // 抽象方法：留给子类实现具体查询条件
    QueryWrapper<T> createQueryWrapper(Pageable pageable);
    
    // 其他通用方法...
}

// 基础实现类：依赖注入Mapper
public class BaseRepositoryImpl<M extends BaseMapper<T>, T> 
        extends ServiceImpl<M, T> implements BaseRepository<T> {
    
    // 构造函数注入Mapper（依赖注入模式）
    public BaseRepositoryImpl(M mapper) {
        this.baseMapper = mapper;
    }
    
    @Override
    public QueryWrapper<T> createQueryWrapper(Pageable pageable) {
        // 默认实现，可被子类覆盖
        return new QueryWrapper<>();
    }
}

常见问题排查

1. 生成文件为空：检查数据库连接配置和表权限
2. 命名转换无效：确认convertServiceFileName配置是否正确
3. 基类引用错误：确保自定义基类全限定名正确无误

拓展应用：企业级场景解决方案

场景一：多模块项目适配

大型项目通常采用多模块架构，可通过以下配置实现按模块生成Repository：

// 解决多模块代码隔离问题：按业务模块生成代码
List<String> modules = Arrays.asList("user", "order", "product");
for (String module : modules) {
    generator.packageInfo(new PackageConfig.Builder()
        .parent("com.company.project." + module)
        .service("repository")
        .build());
    
    // 指定模块对应的表
    generator.strategy(new StrategyConfig.Builder()
        .addInclude(module + "_%") // 匹配表名前缀
        .build());
        
    generator.execute();
}

实施要点：

• 采用"一模块一Repository"原则，避免跨模块依赖
• 共享基础Repository基类放在公共模块
• 为不同模块配置独立的模板文件

场景二：遗留系统改造

对于已有项目的Repository层改造，可采用增量生成策略：

// 解决遗留系统兼容性问题：只生成新增表的Repository
generator.strategy(new StrategyConfig.Builder()
    .addInclude(getNewTables()) // 动态获取新增表名
    .entityBuilder()
        .enableActiveRecord() // 兼容遗留ActiveRecord模式
    .build());

// 解决文件覆盖问题：增量更新模式
generator.global(new GlobalConfig.Builder()
    .fileOverride(false) // 不覆盖已有文件
    .build());

改造步骤：

1. 为遗留实体类添加必要注解
2. 生成新的Repository接口并继承原有接口
3. 逐步迁移业务逻辑至新Repository实现
4. 验证通过后移除旧有数据访问代码

总结与展望

MyBatis-Plus Generator通过灵活的配置机制和模板引擎，为Repository层代码生成提供了完整解决方案。采用这种方式不仅能将开发效率提升90%以上，还能确保分层架构设计的规范性和一致性 🚀。

随着低代码开发趋势，未来可进一步探索：

• 结合元数据驱动设计，实现Repository层的"零配置"生成
• 开发自定义插件拓展代码生成能力
• 与IDE工具链集成，实现一键式代码生成与更新

通过本文介绍的代码生成最佳实践，开发者可以将更多精力投入到业务逻辑实现而非重复劳动中，真正实现"让MyBatis更简单"的项目愿景 🌟。