MyBatis-Plus代码生成器自定义实体类名处理技巧

在使用MyBatis-Plus代码生成器时，开发者经常会遇到需要自定义生成的实体类名的情况。特别是当项目中采用了特定的命名规范，如需要在类名中添加或去除特定后缀（如"DO"）时，掌握正确的配置方法尤为重要。

问题背景

MyBatis-Plus的代码生成器默认会根据表名自动生成对应的实体类名。当开发者在配置中设置了%sDO这样的命名规则时，生成的所有实体类都会自动带上"DO"后缀。但在某些情况下，开发者可能希望在自定义模板中使用不带后缀的类名，这就需要对生成逻辑进行额外处理。

解决方案

MyBatis-Plus提供了灵活的扩展点，允许开发者在生成代码前对类名进行处理。以下是两种有效的解决方案：

方案一：使用formatNameFunction

在定义文件配置时，可以通过formatNameFunction方法对生成的类名进行自定义处理：

.formatNameFunction(tableInfo -> {
    // 在这里可以自定义处理逻辑
    return tableInfo.getEntityName(); // 返回处理后的类名
})

这种方式可以直接在类名生成阶段进行干预，适用于需要对所有生成的类名进行统一处理的场景。

方案二：通过beforeOutputFile钩子

更灵活的方式是使用beforeOutputFile钩子，在文件输出前对变量进行处理：

injectionConfig().beforeOutputFile((tableInfo, customMap) -> {
    // 获取原始类名
    String originalName = tableInfo.getEntityName();
    // 自定义处理逻辑，如去除DO后缀
    String newEntityName = originalName.replace("DO", "");
    // 将处理后的类名放入自定义变量映射中
    customMap.put("newEntityName", newEntityName);
})

这种方法特别适合以下场景：

1. 只需要在特定模板中使用处理后的类名
2. 需要保留原始类名用于其他用途
3. 处理逻辑较为复杂，需要根据具体情况判断

实际应用建议

1. 保持一致性：无论采用哪种方式，建议在整个项目中保持一致的命名处理逻辑，避免混淆。

2. 模板变量使用：在自定义模板中，可以使用${newEntityName}来引用处理后的类名变量。

3. 复杂逻辑处理：如果命名规则复杂，可以考虑封装一个专门的工具类来处理各种命名转换场景。

4. 文档记录：对于自定义的命名规则，建议在项目文档中明确说明，方便团队其他成员理解。

通过掌握这些技巧，开发者可以灵活应对各种命名规范需求，使生成的代码更符合项目规范，同时保持MyBatis-Plus代码生成器的自动化优势。