从XML到注解：MyBatis-Plus如何用‘约定大于配置’解放你的双手？

在Java持久层框架的演进历程中，开发效率与灵活性始终是一对需要权衡的矛盾。传统MyBatis通过XML配置提供了极高的灵活性，但随之而来的是大量重复的样板代码。而MyBatis-Plus的出现，正在重新定义Java持久层开发的效率边界——它用注解和约定替代繁琐配置，让开发者能够专注于业务逻辑而非重复劳动。

1. 开发范式的根本转变

1.1 XML配置时代的困境

在传统MyBatis中，一个简单的CRUD操作需要完整的配置链条：

<!-- UserMapper.xml -->
<mapper namespace="com.example.mapper.UserMapper">
    <select id="selectById" resultType="User">
        SELECT * FROM user WHERE id = #{id}
    </select>
    <insert id="insert" parameterType="User">
        INSERT INTO user(name,age) VALUES(#{name},#{age})
    </insert>
</mapper>

对应的Java接口必须严格匹配XML中的定义：

public interface UserMapper {
    User selectById(Long id);
    int insert(User user);
}

这种模式存在三个显著痛点：

• 维护成本高 ：任何字段变更都需要同步修改XML和Java接口
• 重复劳动多 ：相似业务的SQL语句需要反复编写
• 调试困难 ：XML中的SQL错误往往在运行时才能发现

1.2 约定优于配置的哲学

MyBatis-Plus通过四个核心约定彻底改变了这一局面：

1. 字段映射约定 ：默认采用驼峰转下划线命名规则（如userName → user_name）
2. 主键约定 ：默认认为 id 字段是主键，无需特殊声明
3. CRUD约定 ：基础操作方法名与SQL操作自动对应（如selectById → WHERE id=#{id}）
4. 逻辑删除约定 ：通过 @TableLogic 注解声明逻辑删除字段

这些约定使得80%的常规操作不再需要显式配置，开发者只需关注剩余的20%特殊场景。

2. 注解驱动的开发革命

2.1 实体类即配置中心

MyBatis-Plus将配置信息从XML迁移到了实体类注解：

@TableName("sys_user") // 显式指定表名
public class User {
    @TableId(type = IdType.AUTO) // 自增主键
    private Long id;
    
    @TableField("user_name") // 字段映射
    private String name;
    
    @TableLogic // 逻辑删除标记
    private Integer deleted;
}

这种声明式配置具有三大优势：

• 编译时检查 ：注解错误会在编译阶段暴露
• 代码导航 ：IDE可以直接跳转到相关定义
• 集中管理 ：所有配置与实体类共存，无需多文件切换

2.2 动态SQL的注解方案

对于复杂查询，MyBatis-Plus提供了强大的条件构造器：

// 构建查询条件
LambdaQueryWrapper<User> query = new LambdaQueryWrapper<>();
query.select(User::getName, User::getAge)
     .like(User::getName, "张")
     .between(User::getAge, 20, 30)
     .orderByDesc(User::getCreateTime);

// 执行查询
userMapper.selectList(query);

这种链式API不仅类型安全，还能自动生成最优化的SQL语句。对比传统MyBatis的XML方式：

<select id="selectUsers" resultType="User">
    SELECT name, age FROM user 
    WHERE name LIKE CONCAT('%',#{name},'%')
    AND age BETWEEN #{minAge} AND #{maxAge}
    ORDER BY create_time DESC
</select>

注解方式减少了60%的代码量，且完全避免了SQL字符串拼接的错误风险。

3. 开箱即用的增强功能

3.1 通用Service层封装

MyBatis-Plus的 IService 接口封装了常见业务模式：

public interface UserService extends IService<User> {
    // 自定义扩展方法
    List<User> findActiveUsers();
}

@Service
public class UserServiceImpl extends ServiceImpl<UserMapper, User> 
    implements UserService {
    
    @Override
    public List<User> findActiveUsers() {
        return lambdaQuery()
            .eq(User::getStatus, 1)
            .list();
    }
}

内置方法对比：

方法名	等效SQL	传统MyBatis实现行数
save(entity)	INSERT INTO ...	15+ (XML+接口)
getById(id)	SELECT * WHERE id=#{id}	10+
updateById	UPDATE ... WHERE id=#{id}	15+

3.2 自动分页与性能优化

分页插件只需简单配置：

@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor paginationInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor());
        return interceptor;
    }
}

使用时无需手动计算分页参数：

Page<User> page = new Page<>(1, 10); // 第1页，每页10条
Page<User> result = userService.page(page, queryWrapper);

该分页方案相比原生MyBatis的 RowBounds 有显著性能提升：

1. 物理分页 ：自动生成 LIMIT 语句而非内存分页
2. 计数优化 ：对无 GROUP BY 的简单查询会智能转换为 COUNT(*)
3. 多数据库支持 ：自动适配MySQL、Oracle等不同方言

4. 当约定不够时：灵活扩展方案

4.1 自定义SQL注入

对于特殊SQL需求，仍可保留XML方式：

public interface CustomUserMapper extends BaseMapper<User> {
    @Select("SELECT * FROM user WHERE age > #{minAge}")
    List<User> selectAdults(@Param("minAge") int minAge);
    
    @Update("UPDATE user SET status=#{status} WHERE id=#{id}")
    int updateStatus(@Param("id") Long id, @Param("status") int status);
}

4.2 多租户方案实现

通过实现 TenantLineInnerInterceptor 可以快速构建SaaS应用：

public class MyTenantLineHandler implements TenantLineHandler {
    @Override
    public String getTenantIdColumn() {
        return "tenant_id";
    }
    
    @Override
    public Expression getTenantId() {
        return new StringValue("当前租户ID");
    }
    
    @Override
    public boolean ignoreTable(String tableName) {
        return !"user".equals(tableName); // 指定需要过滤的表
    }
}

这种设计既保持了约定的简洁性，又为特殊场景提供了逃生舱口。实际项目中，约85%的操作可以使用约定实现，剩余15%的特殊需求通过扩展机制解决。