3个步骤实现MyBatis-Plus Repository层自动生成：从配置到落地

一、问题：传统数据访问层的架构痛点

在企业级应用开发中，数据访问层的设计往往面临两个核心挑战：如何保证架构规范性与提升开发效率。传统MyBatis-Plus自动生成方案主要聚焦于Service层和Mapper层，导致项目中出现多种数据访问模式并存的情况：有的团队直接使用Mapper接口，有的团队封装Service层，还有的团队尝试实现Repository模式却缺乏统一标准。

1.1 架构一致性问题

当项目规模超过50个实体类时，缺乏规范的数据访问层设计会导致：

• 接口命名混乱（如同时存在getById、findById、selectById等方法）
• 事务边界不清晰（业务逻辑与数据访问混杂）
• 测试难度增加（不同实现方式需要不同测试策略）

1.2 开发效率瓶颈

手动编写Repository层代码时，开发者需要重复完成：

• 定义接口继承关系
• 实现通用CRUD方法
• 配置事务管理
• 编写分页查询逻辑

💡 提示：这些重复劳动约占数据访问层开发工作量的60%，通过合理配置代码生成器可以完全自动化。

📌 要点总结：Repository模式能够有效解决数据访问层的架构一致性问题，但手动实现成本高。MyBatis-Plus Generator提供了灵活的扩展机制，可以通过配置实现Repository层的自动生成。

二、方案：Spring Data JPA风格的Repository生成策略

MyBatis-Plus作为MyBatis的增强工具，其代码生成器(AutoGenerator)支持通过策略配置实现自定义代码结构。我们将通过包路径重定向、命名规则转换和基类继承三个关键步骤，实现Spring Data JPA风格的Repository层自动生成。

2.1 环境准备与项目初始化

首先确保你的项目满足以下环境要求：

• JDK 8+
• MyBatis-Plus 3.5.0+
• Spring Boot 2.5+（如使用Spring环境）

你可以通过以下命令快速创建一个支持MyBatis-Plus的Spring Boot项目：

git clone https://gitcode.com/baomidou/mybatis-plus
cd mybatis-plus
./gradlew bootRun

预期效果：项目成功启动，数据库连接正常，基础CRUD功能可正常工作。

2.2 核心配置实现

2.2.1 包结构重定向

通过修改PackageConfig，将默认的Service层包路径重定向为Repository层：

// 包配置
PackageConfig packageConfig = new PackageConfig()
    .setParent("com.example")          // 父包名
    .setEntity("entity")              // 实体类包
    .setMapper("mapper")              // Mapper接口包
    .setService("repository")         // Repository接口包
    .setServiceImpl("repository.impl"); // Repository实现类包

2.2.2 命名规则转换

配置StrategyConfig，将生成的文件名称转换为JPA风格的Repository命名：

// 策略配置
StrategyConfig strategyConfig = new StrategyConfig()
    .setServiceBuilder(new ServiceStrategyBuilder()
        .convertServiceFileName(entityName -> "I" + entityName + "Repository")
        .convertServiceImplFileName(entityName -> entityName + "RepositoryImpl")
        .superServiceClass(BaseRepository.class)
        .superServiceImplClass(BaseRepositoryImpl.class)
    );

💡 提示：接口名以"I"开头是为了与Spring Data JPA的命名习惯保持一致，便于团队成员理解和使用。

2.2.3 自定义基类设计

创建Repository层的基础接口和实现类，封装通用操作：

// 基础Repository接口
public interface BaseRepository<T> extends IService<T> {
    // 扩展通用方法
    Page<T> findByPage(Pageable pageable);
    List<T> findByExample(T example);
}

// 基础Repository实现类
public class BaseRepositoryImpl<T> extends ServiceImpl<BaseMapper<T>, T> implements BaseRepository<T> {
    @Override
    public Page<T> findByPage(Pageable pageable) {
        // 实现分页查询逻辑
        return PageHelper.startPage(pageable.getPageNum(), pageable.getPageSize())
            .doSelectPageInfo(() -> baseMapper.selectList(null));
    }
    
    @Override
    public List<T> findByExample(T example) {
        // 实现条件查询逻辑
        QueryWrapper<T> queryWrapper = new QueryWrapper<>(example);
        return baseMapper.selectList(queryWrapper);
    }
}

预期效果：生成的Repository接口自动继承BaseRepository，实现类自动继承BaseRepositoryImpl并拥有所有通用方法。

📌 要点总结：通过包路径重定向、命名规则转换和自定义基类三个步骤，可以实现Spring Data JPA风格的Repository层自动生成。这种方式既保留了MyBatis-Plus的灵活性，又提升了架构一致性。

三、验证：从配置到落地的完整实践

3.1 完整配置示例

将上述配置整合到AutoGenerator中，形成完整的代码生成器配置：

public class RepositoryGenerator {
    public static void main(String[] args) {
        // 数据源配置
        DataSourceConfig dataSourceConfig = new DataSourceConfig
            .Builder("jdbc:mysql://localhost:3306/test", "root", "password")
            .build();
            
        // 全局配置
        GlobalConfig globalConfig = new GlobalConfig
            .Builder()
            .author("Your Name")
            .outputDir(System.getProperty("user.dir") + "/src/main/java")
            .build();
            
        // 整合所有配置
        AutoGenerator generator = new AutoGenerator(dataSourceConfig)
            .global(globalConfig)
            .packageInfo(packageConfig)
            .strategy(strategyConfig);
            
        // 执行生成
        generator.execute();
    }
}

你可以通过以下命令执行代码生成：

java -cp target/classes com.example.RepositoryGenerator

3.2 生成结果验证

成功执行后，项目将生成如下结构的代码：

src/main/java/com/example/
├── entity
│   └── User.java
├── mapper
│   └── UserMapper.java
└── repository
    ├── IUserRepository.java
    └── impl
        └── UserRepositoryImpl.java

其中，IUserRepository接口将自动继承BaseRepository，包含所有通用方法：

public interface IUserRepository extends BaseRepository<User> {
    // 自动生成的接口，无需手动编写
}

3.3 常见误区对比表

常见误区	正确做法	影响
直接使用Mapper接口	通过Repository层封装	架构不清晰，事务管理困难
每个实体类单独编写Repository	使用基类统一实现	代码冗余，维护成本高
忽略接口命名规范	统一使用IxxxRepository	可读性差，团队协作困难
业务逻辑写在Repository层	保持Repository层纯净，业务逻辑放在Service层	职责混乱，难以测试

📌 要点总结：通过完整的配置和执行验证，我们成功实现了Repository层的自动生成。这种方式不仅提升了开发效率，还保证了架构的规范性和一致性。

四、扩展思考：技术选型的决策过程

在选择数据访问层架构时，我们需要考虑以下因素：

1. 团队熟悉度：如果团队已有Spring Data JPA经验，采用Repository模式可以降低学习成本
2. 项目规模：小型项目可能直接使用Mapper接口更简单，大型项目则需要更规范的架构
3. 性能要求：对于高性能场景，可能需要直接使用MyBatis的SQL优化能力
4. 生态集成：如果项目需要与Spring生态深度集成，Repository模式更具优势

建议在项目初期就确定数据访问层的架构风格，并通过代码生成器确保规范的执行。随着项目的发展，可以通过扩展BaseRepository来添加更多通用功能，而无需修改已有代码。

附录：故障排查指南

常见问题及解决方法

1. 生成的Repository没有继承自定义基类

   • 检查StrategyConfig中的superServiceClass配置是否正确
   • 确保基类的全限定名拼写正确

2. 包路径不符合预期

   • 检查PackageConfig的各个包路径配置
   • 确认outputDir是否设置正确

3. 生成的方法与预期不符

   • 检查自定义基类中的方法定义
   • 确认是否正确实现了IService接口

4. 执行生成时报错

   • 检查数据库连接配置
   • 确认数据库驱动是否添加到依赖中
   • 检查数据表是否存在

通过以上步骤，你可以快速定位并解决Repository层自动生成过程中的常见问题，确保整个方案的顺利实施。