从零开始：MyBatis-Plus Generator 实现Repository层代码实战指南

在企业级应用开发中，数据访问层的设计往往直接影响项目的可维护性和扩展性。作为MyBatis的增强工具，MyBatis-Plus提供了强大的代码生成器功能，但很多开发者在实践中仍面临如何将其与Repository模式结合的挑战。本文将带你一步步实现Repository层的自动生成，解决传统开发模式中的架构不规范、重复劳动和扩展性不足等问题。

痛点分析：传统数据访问层开发的三大困境

在没有规范的Repository层设计时，你可能会遇到这些典型问题：

场景一：架构分层混乱

当Service层直接依赖Mapper接口时，业务逻辑与数据访问逻辑紧密耦合。随着项目迭代，你会发现Service类中充斥着大量查询条件拼接代码，既难以维护又违反单一职责原则。

场景二：命名风格不统一

团队开发中，有人习惯用UserDao，有人偏好UserMapper，还有人使用UserRepository。这种命名混乱不仅增加代码理解成本，还可能导致同一功能的实现方式千差万别。

场景三：通用方法重复开发

每个数据访问接口都需要重复定义CRUD方法，即使使用了MyBatis-Plus的BaseMapper，仍需在Service层封装通用业务逻辑，造成大量重复代码。

方案设计：Repository模式与代码生成器的融合思路

Repository模式如同数据访问层的"翻译官"，它将领域模型与数据映射层解耦，让业务逻辑专注于领域规则而非数据操作细节。MyBatis-Plus Generator则像一台"代码生产机"，能按照预定规则批量产出标准化代码。将两者结合，就能构建出既规范又高效的数据访问层架构。

核心设计原则

• 职责分离：Repository接口定义数据访问契约，实现类处理具体技术细节
• 面向接口编程：业务层仅依赖Repository接口，不关心具体实现
• 标准化命名：统一接口与实现类的命名规则，提升代码可读性

实践指南：三步实现Repository层自动生成

1. 准备工作：搭建基础环境

首先确保你的项目中已引入MyBatis-Plus Generator依赖。如果是Maven项目，可以在pom.xml中添加：

<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-generator</artifactId>
    <version>最新版本</version>
</dependency>

同时，你需要创建两个基础类：

• IRepository<T>：Repository接口基类，定义通用数据访问方法
• CrudRepository<T>：Repository实现类基类，继承ServiceImpl并实现IRepository

2. 配置包路径映射

包路径配置决定了生成代码的存放位置，合理的包结构能显著提升项目可维护性：

AutoGenerator generator = new AutoGenerator(dataSourceConfig);
generator.packageInfo(new PackageConfig()
    .parent("com.example")        // 父包名
    .entity("domain")            // 实体类包
    .mapper("dao")               // Mapper接口包
    .service("repository")       // Repository接口包
    .serviceImpl("repository.impl") // 实现类包
);

💡 为什么这么做：将Service层重命名为Repository层，明确表达其数据访问职责，同时保持与领域驱动设计(DDD)的架构风格一致。

3. 定制命名规则

通过策略配置，将默认的Service命名转换为Repository风格：

generator.strategy(new StrategyConfig()
    .serviceBuilder()
        .convertServiceFileName(entityName -> "I" + entityName + "Repository")
        .convertServiceImplFileName(entityName -> entityName + "Repository")
        .superServiceClass(IRepository.class)
        .superServiceImplClass(CrudRepository.class)
);

⚠️ 注意：确保IRepository和CrudRepository已在项目中定义，否则会导致编译错误。

实现效果：代码结构对比

传统Service模式	Repository模式
com.example.service.UserService	com.example.repository.IUserRepository
com.example.service.impl.UserServiceImpl	com.example.repository.impl.UserRepository
依赖BaseMapper	实现IRepository接口
业务逻辑与数据访问混合	职责单一，接口清晰

执行生成器后，你将得到规范的Repository层代码，其中接口继承自IRepository，实现类继承自CrudRepository并依赖Mapper接口，完美实现了业务逻辑与数据访问的解耦。

进阶技巧：三个实用场景解决方案

场景一：添加通用分页方法

需求描述：所有Repository都需要支持基于Pageable的分页查询 实现思路：在IRepository中定义默认方法 关键代码：

public interface IRepository<T> {
    default Page<T> findByPage(Pageable pageable) {
        // 实现分页逻辑
    }
}

场景二：多数据源支持

需求描述：为不同数据源生成独立的Repository层 实现思路：创建多个AutoGenerator实例，配置不同数据源和包路径 关键代码：

// 主数据源生成器
AutoGenerator mainGenerator = new AutoGenerator(mainDataSourceConfig);
mainGenerator.packageInfo(new PackageConfig().moduleName("repository.main"));

// 从数据源生成器
AutoGenerator slaveGenerator = new AutoGenerator(slaveDataSourceConfig);
slaveGenerator.packageInfo(new PackageConfig().moduleName("repository.slave"));

场景三：生成带注释的接口文档

需求描述：自动为Repository接口添加Javadoc注释 实现思路：自定义TemplateEngine，在生成代码时添加注释模板 关键代码：

generator.templateEngine(new FreemarkerTemplateEngine() {
    @Override
    public void writer(Map<String, Object> objectMap, String templatePath, String outputFile) {
        // 添加注释逻辑
        super.writer(objectMap, templatePath, outputFile);
    }
});

常见问题排查

问题一：生成的Repository接口没有继承IRepository

原因：superServiceClass配置错误或类路径不正确 解决方案：检查配置中的类全限定名是否正确，确保IRepository在项目中可访问

问题二：生成路径与预期不符

原因：outputDir配置错误或相对路径计算偏差 解决方案：使用绝对路径配置outputDir，如System.getProperty("user.dir") + "/src/main/java"

问题三：命名转换没有生效

原因：策略配置顺序错误或方法调用不正确 解决方案：确保在serviceBuilder()之后调用convertServiceFileName方法

通过本文介绍的方法，你可以利用MyBatis-Plus Generator快速构建规范的Repository层，既保留了MyBatis-Plus的高效开发特性，又遵循了领域驱动设计的架构思想。这种方式不仅能提升团队协作效率，还能为项目后续的扩展和维护奠定坚实基础。

希望这篇指南能帮助你在实际项目中更好地应用MyBatis-Plus，如果你有其他关于Repository层设计的心得，欢迎在评论区分享交流！