MyBatis-Plus中重写selectPage方法的正确姿势-CSDN博客

MyBatis-Plus中重写selectPage方法的正确姿势

【免费下载链接】mybatis-plus mybatis 增强工具包，简化 CRUD 操作。文档 http://baomidou.com 低代码组件库 http://aizuda.com 项目地址: https://gitcode.com/baomidou/mybatis-plus

MyBatis-Plus作为MyBatis的增强工具，提供了许多便捷的CRUD操作方法，其中分页查询selectPage()是开发中常用的功能之一。本文将深入探讨如何在MyBatis-Plus中正确重写selectPage方法，解决开发者在实际项目中可能遇到的覆盖问题。

问题背景

在MyBatis-Plus的BaseMapper接口中，selectPage()方法默认实现会调用selectList()方法来完成分页查询。许多开发者希望在XML映射文件中重写这个方法，但发现直接重写selectPage()并不生效，而重写selectList()却能正常工作。

原因分析

这种现象源于MyBatis-Plus的设计机制。BaseMapper中的selectPage()是一个default方法，其内部实现确实调用了selectList()。当我们在XML中重写selectList()时，MyBatis会优先使用XML中的实现；但对于selectPage()，由于它是接口的default方法，直接XML重写不会覆盖默认实现。

解决方案

方案一：使用高版本JDK特性（推荐）

在JDK 1.8及以上版本中，可以直接在Mapper接口中重写selectPage()方法：

@Select("SELECT * FROM your_table WHERE ${ew.sqlSegment}")
@Override
<P extends IPage<YourEntity>> P selectPage(P page, @Param("ew") Wrapper<YourEntity> queryWrapper);

这种方法简洁明了，利用了JDK 8的default方法特性，直接在接口层面覆盖默认实现。

方案二：间接重写方法

对于必须使用低版本JDK或需要更复杂SQL逻辑的情况，可以采用间接重写的方式：

在Mapper接口中添加一个新方法：

<P extends IPage<YourEntity>> P customSelectPage(P page, @Param("ew") Wrapper<YourEntity> wrapper);

重写default selectPage方法调用新方法：

@Override
default <P extends IPage<YourEntity>> P selectPage(P page, Wrapper<YourEntity> ew) {
    return customSelectPage(page, ew);
}

在XML中实现customSelectPage方法：

<select id="customSelectPage" resultType="your.package.YourEntity">
    SELECT * FROM your_table
    <where>
        ${ew.sqlSegment}
    </where>
</select>

注意事项

参数命名一致性：Wrapper参数必须使用@Param("ew")注解或保持参数名为ew，否则会报参数找不到的错误。
返回类型匹配：重写方法时必须保持与原始方法相同的泛型返回类型<P extends IPage<T>> P，使用具体类如Page 或IPage 会导致编译错误。
SQL注入防护：使用${ew.sqlSegment}时要确保查询条件已经过合理验证，防止SQL注入。

最佳实践建议

对于简单查询，优先使用方案一，代码更简洁。
对于复杂分页查询（如多表关联），建议使用方案二，将复杂逻辑放在XML中。
保持命名一致性，自定义方法名应能清晰表达其用途。
考虑在自定义分页方法中添加性能监控逻辑，便于后期优化。

通过以上方法，开发者可以灵活地重写MyBatis-Plus的分页查询方法，满足各种业务场景的需求，同时保持代码的整洁和可维护性。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考