MyBatis PageHelper 最佳实践

最新推荐文章于 2024-06-24 13:28:13 发布

转载最新推荐文章于 2024-06-24 13:28:13 发布 · 264 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：http://www.iocoder.cn/zhishixingqiu/?vip\x26amp;amp;mp

文章标签：

#数据库 #中间件 #java #spring #编程语言

本文精讲PageHelper分页插件的使用技巧与原理，包括基本使用、进阶使用及源码解析等内容，帮助开发者掌握高效分页技术。

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 8:55 更新文章，每天掉亿点点头发...

源码精品专栏

来源：blog.youkuaiyun.com/NOT_TWO_CHEN/article/details/109230267

一。开发准备
- 1.开发工具
- 2.开发环境
- 3.开发依赖
二。技术文档
- 1.基于SpringBoot
- 2.基于MyBatis
- 3.集成的PageHelper
三。应用讲解
- 1.基本使用
- 2.进阶使用
- 3.原始分析
- 拓展
四。总结

一。开发准备

1.开发工具

IntelliJ IDEA 2020.2.3

2.开发环境

红帽开放JDK 8u256
Apache Maven 3.6.3

3.开发依赖

弹簧靴

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
</dependency>

MyBatis

<dependency>
 <groupId>org.mybatis.spring.boot</groupId>
 <artifactId>mybatis-spring-boot-starter</artifactId>
 <version>2.1.3</version>
</dependency>

页面助手

<dependency>
 <groupId>com.github.pagehelper</groupId>
 <artifactId>pagehelper-spring-boot-starter</artifactId>
 <version>1.3.0</version>
</dependency>

二。技术文档

1.基于SpringBoot

SpringBoot官方文档
SpringBoot中文社区

2.基于MyBatis

MyBatis官方文档

3.集成的PageHelper

PageHelper开源仓库

三。应用讲解

1.基本使用

在实际项目运用中，PageHelper的使用非常便利快捷，仅通过PageInfo+PageHelper两个类，就可以完成分页功能，而往往这种最简单的集成使用方式，却在很多实际应用场景中，没有得到充分的开发利用。

接下来是我们最常见的使用方式：

public PageInfo<ResponseEntityDto> page(RequestParamDto param) {
 PageHelper.startPage(param.getPageNum(), param.getPageSize());
 List<ResoinseEntityDto> list = mapper.selectManySelective(param);
 PageInfo<ResponseEntityDto> pageInfo = (PageInfo<ResponseEntityDto>)list;
 return pageInfo;
}

在某种程度上而言，上述写法的确是符合PageHelper的使用规范：

在集合查询前使用PageHelper.startPage(pageNum,pageSize)，并且中间不能穿插执行其他SQL

但是作为开发者的我们，往往只有在追求完美和极致的道路上才能够寻得突破和可能性；以下是合理且规范的基本使用：

public PageInfo<ResponseEntityDto> page(RequestParamDto param) {
 return PageHelper.startPage(param.getPageNum(), param.getPageSize())
     .doSelectPageInfo(() -> list(param))
}
public List<ResponseEntityDto> list(RequestParamDto param) {
 return mapper.selectManySelective(param);
}

常问问题

1.为什么要重新声明一个列表函数？

答：经常在很多实际业务应用场景中，分页查询是基于大数据量的表格展示需求来进行的。

然而很多时候，譬如：内部服务的互相调用，OpenAPI的提供。

甚至在某些以前以前分离联调的业务场景中，也是同样需要一个非分页集合查询接口来提供服务的。

另外，暂时以上因素抛开不谈，我们可以根据上述写法来定义和规范某些东西

譬如：状语从句：分页查询集合的分离状语从句：解耦（解耦详情请看进阶使用），

分页请求的请求和响应与实际业务参数的分离（详情请看进阶使用）等等...

2.`doSelectPageInfo`是什么？

答：doSelectPageInfo是PageHelper.startPage()函数返回的Page内置实例内置的函数，该函数可以Lambda通过重新的形式通过额外的Function来进行查询而不需要再进行多余的PageInfo与List转换，而doSelectPageInfo参数则是PageHelper内置的Function(ISelect)接口实现达到转换PageInfo的目的

3.这种写法的代码量看起来过多反多？

答：正如同①中所描述的，就位量而言，确实没有更进一步的简化，但是再某些业务场景中，在已具有功能list接口的情况下，是一种更直观的优化（优化详情请看进阶使用）

2.进阶使用

先看代码，再谈解析：

import com.github.pagehelper.PageHelper;
import com.github.pagehelper.PageInfo;

import java.util.List;

/**
 * @param <Param> 泛型request
 * @param <Result> 泛型response
 */
public interface BaseService<Param, Result> {

    /**
     * 分页查询
     *
     * @param param 请求参数DTO
     * @return 分页集合
     */
    default PageInfo<Result> page(PageParam<Param> param) {
        return PageHelper.startPage(param).doSelectPageInfo(() -> list(param.getParam()));
    }

    /**
     * 集合查询
     *
     * @param param 查询参数
     * @return 查询响应
     */
    List<Result> list(Param param);
}

可以BaseService看到可以作为Service通用通用接口的封装和声明，而作为通用分页接口页面函数却在此处利用interface特有关键字直接声明default了page函数的方法体body

import com.github.pagehelper.IPage;
import lombok.Data;
import lombok.experimental.Accessors;

@Data // 为省略冗余代码使用lombok 实际应有常规Getter/Setter Construction toString等
@Accessors(chain = true) // 此lombok注解是为了实现 Entity伪Build 譬如: entity.setX(x).setY(y)
public class PageParam<T>  implements IPage {

    //  description = "页码", defaultValue =  1
    private Integer pageNum = 1;

    // description = "页数", defaultValue = 20
    private Integer pageSize = 20;

    // description = "排序", example = "id desc"
    private String orderBy;

    //  description = "参数"
    private T param;

    public PageParam<T> setOrderBy(String orderBy) {
        this.orderBy = orderBy; // 此处可优化 优化详情且看解析
        return this;
    }
}

在BaseService中我们看到了一个新的PageParam，参考了PageInfo替换包装/声明/分离分页参数和业务参数，并且参数类型为泛型，即支持任何数据类型的业务参数同时也可以看到PageParam实现了IPage接口，并且多了一个orderBy属性预设

import common.base.BaseService;
import dto.req.TemplateReqDto;
import dto.resp.TemplateRespDto;

public interface TemplateService extends BaseService<TemplateReqDto, TemplateeRespDto> {
    // 同为interface接口, 业务Service只需要继承BaseService
    // 并根据实际使用场景声明请求参数和响应结果的Entity实体即可
}

在实际应用中，只需要声明我们通用的业务查询请求参数和响应结果即可

import dto.req.TemplateReqDto;
import dto.resp.TemplateRespDto;
import service.TemplateService;
import persistence.mapper.TemplateMapper;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;

import java.util.List;

@Slf4j // 基于lombok自动生成logger日志记录实例
@Service // SpringBoot中注册Service Bean的注解
@RequiredArgsConstructor // 基于lombok根据类所有final属性生成构造函数 即可完成Spring构造注入
public class TemplateServiceImpl implements TemplateService {

    private final TemplateMapper mapper;

    @Override
    public List<TemplateRespDto> list(TemplateReqDto param) {
        return mapper.selectManySelective(param) // 可根据实际情况将实体做转换
    }
}

实现类中也只需要重建list方法体，将实际业务场景中需要处理的业务逻辑处理和查询方法写入其中，并不需要关心分页功能

@Slf4j // 同上
@RestController // SpringBoot中注册Controller Bean的注解
@RequiredArgsConstructor // 同上
public class TemplateController {

    public final TemplateService service;

    /**
     * 分页查询
     *
     * @param pageParam 分页查询参数
     * @return 分页查询响应
     */
    @PostMapping(path = "page")
    public PageInfo<Result> page(@RequestBody PageParam<Param> pageParam) {
        return service.page(pageParam);
    }

    /**
     * 集合查询
     *
     * @param listParam 集合查询参数
     * @return 集合查询响应
     */
    @PostMapping(path = "list")
    public List<Result> list(@RequestBody Param listParam) {
        return service.list(listParam);
    }
}

最后编码Controller接口时，也只需要直接调用service.page即可，而请求参数直接用PageParam包装，将分页参数和业务参数分离，在前称为接口联调中，保持这种分离规范，可以减少的降低沟通和开发成本

常问问题

1.`BaseService`作为`interface`，`page`为什么可以声明方法体？

答：Java8中新特性之一就是为interface接口类增加了static/default方法，即声明方法后，其子类或实现都将具有这些方法，可以直接调用而在此为Page方法声明default是因为page函数只关注分页参数和分页响应，脱离了业务场景，方法体大相径庭，所以索性抽象定义出来，免去了其实现的复杂重复过程

2.`PageParam`的声明有什么意义？实现`IPage`是为了什么？

答：PageParam是参考PageInfo编写的类（不确定往后PageHelper是否会封装此类，兴许我可以提个Issue上去，也参与开源框架的开发）编写此类的目的就是为了分离分页和业务数据，让开发者专注于业务的实现和开发，也是同时对分页查询API的一种规范，无论是请求还是响应都将分页相关的数据抽离出来，使用单独而实现IPage则的英文因为IPage作为PageHelper内置的interface，在不了解它更多意义上的作用前，可以作为我们分页参数声明的一种规范，而IPage中也只声明了三个方法，分别是pageNum/pageSize/orderBy的Getter方法，另外在源码分析中，我将会意识到实现此接口更深层的意义

3.`PageParam`中除了常规的`pageNum/pageSize`，为什么还需要一个`orderBy`？

答：常规的分页查询中只需要pageNum/pageSize即可完成分页的目的，但是经常伴随着分页查询的还有选择排序，而orderBy则是专注于SQL的动态传参排序

4.`orderBy`如何使用？会有什么问题吗？

答：orderBy和pageNum/pageSize一样，都是Pagehelper通过MyBatis拦截器，在查询查询中注入进去的，所以在前端传参时，orderBy参数应为数据库column desc/asc这种形式，多分段排序则可以用逗号（，）拼接，例如如：columnA desc,columnB，但是另外一部分又存在两个问题，首先就是大多数数据库表分区设计中，都会使用蛇形案例命名，而非常规开发中的驼峰案例命名，所以存在一次转换，而这种转换可以分配给前端传参时，也可以分配给介入接参时。第二就是这样赤裸裸的将分类插入到接口中，会存在的顺序由SQL注入的风险，所以在实际使用过程中，我们需要通过某种手段去校正和排查orderBy的传参是否合法，例如如用正则则表达式匹配参数值只能包含order by语法中必要的值，例如扩展名desc or asc，，可以包含特殊字符/数据库关键字等

5.`pageNum/pageSize`一定需要给预设值吗？

答：通过阅读PageHelper二进制代码，我们知道在Page查询参数为null时，它并不会导致其本身值，不会进行额外的处理，以至于导致分页失败，而给值，也为了防止防前重新调试接口过程中可能会出现的各种意外

3.原始分析

首先我们看PageHelper.startPage(param)过程中发生了什么：

public static <E> Page<E> startPage(Object params) {
 Page<E> page = PageObjectUtil.getPageFromObject(params, true);
 Page<E> oldPage = getLocalPage();
 if (oldPage != null && oldPage.isOrderByOnly()) {
  page.setOrderBy(oldPage.getOrderBy());
 }
 setLocalPage(page);
 return page;
}

这是PageHelper继承（extend）的抽象类PageMethod中的一个静态方法

再看代码第一行Page<E> page = PageObjectUtil.getPageFromObject(params, true)发生了什么：

public static <T> Page<T> getPageFromObject(Object params, boolean required) {
 if (params == null) {
  throw new PageException("无法获取分页查询参数!");
 } else if (params instanceof IPage) {
  IPage pageParams = (IPage)params;
  Page page = null;
  if (pageParams.getPageNum() != null && pageParams.getPageSize() != null) {
   page = new Page(pageParams.getPageNum(), pageParams.getPageSize());
  }
  if (StringUtil.isNotEmpty(pageParams.getOrderBy())) {
   if (page != null) {
    page.setOrderBy(pageParams.getOrderBy());
   } else {
    page = new Page();
    page.setOrderBy(pageParams.getOrderBy());
    page.setOrderByOnly(true);
   }
  }
  return page;
 } else {
        ... // 此处我只截取了部分代码片段, 以上是较为重要的一块
 }
}

可以看到在此方法中，会先判断params是否为空，再而通过instanceof判断是否为IPage子类或实现类如果以上两个if/else皆不满足，则PageHelper不要在我省略贴出的代码中通过大量的反射代码来获取pageNum/pageSize以及orderBy。总所皆知，反射在Java中虽然广泛应用，并且作为语言独有特性之一，被广大开发者的喜爱，但是反射在某种程度上，是需要性能成本的，甚至于现阶段很多主流的框架和技术，都在尽量减少反射的运用，以防止框架性能过差，被市场淘汰。那么到此为止，我们也终于解释并知道了为什么PageParam要实现IPage接口了，在这里的代码中可以直接通过接口获取到分页参数，而不需要通过有损性能的反射获取PageHelper需要的参数

看继续startPage中的后续代码：

public abstract class PageMethod {
    protected static final ThreadLocal<Page> LOCAL_PAGE = new ThreadLocal();
    protected static boolean DEFAULT_COUNT = true;

    public PageMethod() {
    }

    protected static void setLocalPage(Page page) {
        LOCAL_PAGE.set(page);
    }

    public static <T> Page<T> getLocalPage() {
        return (Page)LOCAL_PAGE.get();
    }
 ...
 ...
}

可以看到PageHelper继承的抽象类PageMethod中声明了一个Page的线程局部变量，而getLocalPage()则是为了获取现代线程中的Page而接下来if (oldPage != null && oldPage.isOrderByOnly())则是判断是否存在旧分页数据，在这里isOrderByOnly通过通过getPageFromObject()我们可以知道，当只存在orderBy参数时，即为true初始，当存在旧分页数据和旧分页数据只有排序参数时，就将旧分页数据的分类参数分为新分页数据的排序参数，然后将新的分页数据page存入本地线程变量中实际应用场景中，这种情况还是比较少，仅排序而不分页，所以某种角度上而言，我们仅当了解便好

接下来再看doSelectPageInfo(ISelect)中发生了什么：

public <E> PageInfo<E> doSelectPageInfo(ISelect select) {
 select.doSelect();
 return this.toPageInfo();
}

可以看到，该方法的实现非常简单明了，就是通过注册声明ISelect接口由开发自定义集合查询方式并由它内部执行，随后便返回PageInfo实体前面我们有提到，PageHelper通过MyBatis拦截器达到分页的目的，那么为什么此处的ISelect.doSelect()执行，就可以返回PageInfo实体呢？实际上这便是拦截器的妙用所在，在select.doSelect()执行时，会触发PageHelper自定义的MyBatis查询拦截器，并通过解析SQL和SQL参数，根据数据库类型，进行分页，例如MySQL的limit，Oracle的Rownum等，同时进行在我们定义的查询SQL之前，PageHelper会重新生成一条select count（*）的SQL率先执行，已达到它定义Page内置分页参数的目的

@Intercepts({@Signature(
    type = Executor.class,
    method = "query",
    args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}
), @Signature(
    type = Executor.class,
    method = "query",
    args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class}
)})
public class PageInterceptor implements Interceptor {
    private volatile Dialect dialect;
    private String countSuffix = "_COUNT";
    protected Cache<String, MappedStatement> msCountMap = null;
    private String default_dialect_class = "com.github.pagehelper.PageHelper";

    public PageInterceptor() {
    }

    public Object intercept(Invocation invocation) throws Throwable {
    ...
    ...
    }
}

以上便是PageHelper内置的自定义MyBatis拦截器，原因代码量过多，为了保证不违反本博文文不对题的原则，此处不再做多余的讲解，如有需要，我可以重新编写一篇博客单独解释并讲解MyBatis的拦截器的概念和原理，深度解析MyBatis的源码

拓展

PageHelper完全有pageNum/pageSize/orderBy这几个参数，更还有pageSizeZero, reasonable参数等可以替代更进阶的分页查询定义，如需更深入的了解，我可以替换写入一遍进阶PageHelper使用，此文仅作为寻常开发使用讲解

四。总结

PageHelper作为GitHub上现在近10K的开源分页框架，也许代码深度和广度不及主流市场框架和技术，虽然在功能的实现和原理上，造轮子的微小不高，源码也很清晰，但是在很大程度上解决了很多基于MyBatis的分页技术难题，简化了并提示了广大开发者的效率，这才是开发者们在开发的路上应该向往并为之拼搏的方向和道路。而我们作为受益者，也不适合预期的进行基本的使用，开发之余，我们也应该关注一些框架的发展，对框架的走向有一定程度的了解，并为之扩大和优化

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：