Spring Boot + PageHelper 实现分页，总结得很全了！

CSDN：https://blog.csdn.net/NOT_TWO_CHEN/php

简书：https://www.jianshu.com/p/a24a9ff323c9html

一. 开发准备

1. 开发工具

IntelliJ IDEA 2020.2.3前端

2. 开发环境

Red Hat Open JDK 8u256java
Apache Maven 3.6.3git

3. 开发依赖

SpringBoot程序员

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

MyBatisgithub

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

PageHelperweb

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

二. 技术文档

1. 基于SpringBoot

SpringBoot 官方文档：https://spring.io/projects/spring-boot面试
SpringBoot 中文社区：https://springboot.io正则表达式

2. 基于MyBatis

MyBatis 官方文档：https://mybatis.org/mybatis-3/zh/index.html

3. 集成PageHelper

PageHelper 开源仓库：https://github.com/pagehelper/Mybatis-PageHelper

Spring Boot 学习理论和实战推荐：

https://github.com/javastacks/spring-boot-best-practice

三. 应用讲解

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*

可是做为Developer的咱们,每每只有在追求完美和极致的道路上才可以寻得突破和机遇; 如下是合理且规范的基本使用:

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);
}

FAQ

1. 为何要从新声明一个list函数?

答: 每每在不少实际业务应用场景中, 分页查询是基于大数据量的表格展现需求来进行的. 然而不少时候,譬如: 内部服务的互相调用,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通用接口的封装和声明，而做为通用分页接口page函数却在此处利用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包装,将分页参数和业务参数分离,在先后端接口联调中,保持这种==分离规范==,能够很大程度上的下降沟通和开发成本。

FAQ

1. `BaseService`做为`interface`,`page`为何能够声明方法体?

答: Java8中新特性之一就是为interface接口类增长了static/default方法,即声明方法后,其子类或实现都将默认具备这些方法,能够直接调用而在此处为Page方法声明default是由于page函数只关注分页参数和分页响应,脱离了业务场景,方法体截然不同,因此索性抽象定义出来,免去了其实现的复杂冗余过程。关注公众号Java技术栈可阅读Java8系列教程。

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拦截器,在query查询中注入进去的,因此在前端传参时,orderBy参数应为数据库column desc/asc这种形式,多字段排序则能够用逗号(,)拼接,譬如: columnA desc,columnB, 可是另一方面又存在两个问题, 第一就是大多数数据库表字段设计中,都会使用==蛇形case==命名,而很是规开发中的==驼峰case==命名,因此存在一层转换,而这种转换能够分配给前端传参时,也能够分配给后端接参时. 第二就是这样赤裸裸的将排序字段暴露在接口中,会存在order by 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是否为null,再而经过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拦截器,因代码量过多,为了保证不违反本博文文不对题的原则,此处再也不作多余讲解。

拓展

PageHelper不只有pageNum/pageSize/orderBy这几个参数,更还有pageSizeZero, reasonable参数等用以更进阶的分页查询定义。

四. 总结

PageHelper做为GitHub上如今近10K的开源分页框架,也许代码深度和广度不及主流市场框架和技术,虽然在功能的实现和原理上,造轮子的难度不高,源码也很清晰,可是在很大程度上解决了不少基于MyBatis的分页技术难题,简化并提示了广大开发者的效率,这才是开发者们在开发的路上应该向往并为之拼搏的方向和道路。

而咱们做为受益者,也不该当仅仅是对其进行基本的使用,开发之余,咱们也应该关注一些框架的拓展,对框架的底层有必定程度上的了解,并为之拓展和优化

此处再次放上PageHelper的开源仓库!

https://mvnrepository.com/artifact/com.github.pagehelper/pagehelper-spring-boot-starter

---END---推荐阅读


代码对比工具，我就用这6个

分享我经常使用的5个免费的在线 SQL 数据库环境，简直太方便了！

Spring Boot 三招组合拳，手把手教你打出优雅的后端接口

MySQL 5.7 vs 8.0，你选那个？网友：我继续原地踏步~



最后，推荐给你们一个有趣有料的公众号：写代码的渣渣鹏，7年老程序员教你写bug,回复 面试|资源 送一你整套开发笔记 有惊喜哦