若依源码解读:神奇的分页实现（分页功能实现的基本流程）

上次在分享若依框架升级mybatis-plus的时候有提到过它的分页功能，今天就和大家详细的介绍若依框架的分页实现方式，首先我们先看到一段代码：

 @GetMapping("/list")
    public TableDataInfo list(SysPost post)
    {
        startPage();
        List list = postService.selectPostList(post);
        return getDataTable(list);
    }

这是若依里面最常见的分页用法，就是在controller方法中 手动加上 startPage() 这么一行代码，mybatis就可自动的实行分页处理。那么究竟是什么魔力让这么一行代码实现了分页功能呢？点开这个方法跟进去，看到源码如下：

如红色箭头所示，若依其实并没有自己实现分页，也没有对分页插件做二次扩展，其实就是用了mybatis的第三方分页插件 PageHelper，这个插件是在ruoyi-common模块中引入的，它的pom依赖如下：

  
            com.github.pagehelper
            pagehelper-spring-boot-starter
  

pagehelper-spring-boot-starter 这个jar最终就依赖了PageHelper

  
            com.github.pagehelper
            pagehelper
    

现在我们知道了若依其实就是使用PageHelper进行分页，那么我们回过头来看 startPage() 这句代码具体是如何实现分页的，顺着代码跟进去：

可以看到 是通过PageUtils这类去调用的，具体源码如下：

/**
 * 分页工具类
 * 
 * @author ruoyi
 */
public class PageUtils extends PageHelper
{
    /**
     * 设置请求分页数据
     */
    public static void startPage()
    {
        PageDomain pageDomain = TableSupport.buildPageRequest();
        Integer pageNum = pageDomain.getPageNum();
        Integer pageSize = pageDomain.getPageSize();
        if (StringUtils.isNotNull(pageNum) && StringUtils.isNotNull(pageSize))
        {
            String orderBy = SqlUtil.escapeOrderBySql(pageDomain.getOrderBy());
            Boolean reasonable = pageDomain.getReasonable();
            PageHelper.startPage(pageNum, pageSize, orderBy).setReasonable(reasonable);
        }
    }

    /**
     * 清理分页的线程变量
     */
    public static void clearPage()
    {
        PageHelper.clearPage();
    }
}

这个类比较简单，startPage方法的有两个职责，一个是获取pageNum,pageSize,orderBy这三个分页参数，第二个就是调用PageHelper.startPage(pageNum, pageSize, orderBy) 这一个方法，这是mybatis分页插件的工具类。PageHelper通过这个方法调用把分页参数设置到ThreadLocal中，然后通过mybatis分页拦截器在ThreadLocal中获取分页参数进行SQL改写，可以想象最终的SQL肯定就是会加上limit ?,? 。这里不过多分析PageHelper本身的分页原理，只学习若依是如何二次包装PageHelper屏蔽分页参数来实现简单分页的。

通过上面的分析我们知道，要实现分页就是要调用PageHelper.startPage(pageNum, pageSize, orderBy)，那么抛开若依的封装我们完全可以在任何Controller方法内部显式的调用就可以了,比如下面这样：

   @GetMapping("/list")
    public TableDataInfo list(SysPost post)
    {
        PageHelper.startPage(pageNum, pageSize, orderBy) ；
        List list = postService.selectPostList(post);
        return getDataTable(list);
    }

那么pageNum, pageSize, orderBy 这三个参数从哪来的呢？在SpringMvc中有很多种方式可以实现，一个是直接绑定到如上面代码中的SysPost对象，一个是通过 RequestAttributes对象的方法getParameter(String name)从URL参数中获取。若依的源码中的实体类如上面的SysPost并没有分页相关的属性，所以若依采用的是第二种方式。大概猜测一下若依这样做的目的可能是觉得分页参数和业务实体是两个不相关的东西，没必要参合在一起，所以就没有让业务实体和分页属性绑定到一起。顺着代码往下看：

红色箭头的这两行代码就是获取分页参数的，然后再跟进
TableSupport.buildPageRequest()看看它是如何获取PageDomain 分页对象的

可以看到内部又是通过一个工具类静态方法
ServletUtils.getParameterToInt获取分页参数的，从这个名字看就知道是通过web 容器获取

如图所示，这几个步骤都是为了获取到RequestAttributes，最终就是通过Spring的一个全局工具类RequestContextHolder去获取的。 Spring的这个工具类提供了普通Bean中获取web请求对象的方式，它是线程安全的，每个请求都有自己的RequestAttributes。获取到RequestAttributes对象后，就可以通过调用getParameter(String name) 获取到http请求中的URL参数了，这里就是上面提到过的pageNum，pageSize,orderBy这些分页参数。通过上面分析，回到若依分页的用法地方：

现在就知道了，为什么这一行代码可以设置分页了，也解释了为什么明明没有入参却可以获取到了请求过来的分页参数，我们重新梳理一下过程：

1. 依托Spring RequestContextHolder从当前线程中获取RequestAttributes
2. 使用RequestAttributes 获取URL三个分页请求参数
3. 调用mybatis分页插件 PageHelper.startPage(pageNum, pageSize, orderBy)

那么若依框架又是如何获取到这些请求的分页参数呢？

首先我们先要了解一下SpringMvc数据绑定的原理。在SpringMvc中，想要把前端的参数绑定到后端对象中有两种基本的方式，一个是前端提交json报文，后端使用@RequestBody 接收。另外一个就是前端把参数挂到URL请求上，如 post/list?pageNum=1&pageSize=10&orderBy=desc ,然后后端直接可以用java对象接收。若依框架用的是第二种方式，但是它只是接收业务参数，不接收分页参数，分页参数则通过RequestAttributes去获取。由此可见，分页参数的获取肯定需要前端的配合，那我们看一下若依的前端代码是如何实现分页参数提交的。

若依的前端是基于vue框架的，vue也如后端一样对请求和响应是有拦截器的。这个拦截器就在src根目录下的request.js

可以看到if(config.method === 'get' && config.params) 这行代码就是先对get请求进行拦截，如果请求参数中有params参数（vue中一般是json对象），则将这个json解析成URL参数。比如页面中的列表查询提交后是一个json 对象{pageNum:1,pageSize:10,orderBy:"desc"}，则需要把这个对象的属性和值解析成URL参如：post/list?pageNum=1&pageSize=10&orderBy=desc。这样就印证了上面分析的java后端是如何获取分页参数的了。

以上就是对若依框架分页的实现原理的源码解读，总结来说就是若依本身并没有重复发明轮子，只是简单包装了一下第三方分页插件，更多的是在web层对分页参数的获取做了技巧性处理，让用户对分页参数无感知。对此，

笔者对这个分页的方式也有自己的一点见解。比如这种方式只能使用get请求，其次就是需要前端代码配合。然后就是后端入参，返参，数据库实体都是一个，这样导致的问就是一个对象太多的属性暴露给前端。笔者认为更好的方式应该是前端需要什么就给什么，数据库的实体对象不暴露给前端。也就是我们经常说的VO,DTO，显然若依没搞这么复杂，就是一个实体到底。