数据分页 | LIXI.FUN

比较朴素的做法

前端发送请求分页的必要数据

{
    pageNum: 1,
    pageSize: 10,
}

后端接收这几个参数

public class Param {
    // 其他参数
    // ...
    private Integer pageNum;
    private Integer pageSize;
}

这里有什么问题呢？

对每个需要分页操作的参数，需要有 pageNum pageSize 这些参数；
对每个需要分页的操作，需要在 sql 中手动显式拼接 LIMIT 之类的分页操作。

参数类里的 page 相关参数拆分

比较朴素的做法是把分页的数据抽出来一个父类，用 Param 继承 BasePage 类，如下：

public class BasePage {
    private Integer pageNum;
    private Integer pageSize;
}

public class Param extends BasePage {
    // 业务参数
    // ...
}

这样只是把写在 Param 里的分页参数，换了个地方，实际还是对于业务的一个强侵入，比如当 Param 需要继承一个比 BasePage 重要程度要高的业务相关类的时候，因为 Java 的单继承机制，分页参数的去向又需要某些迂回操作了。

另一种方式是直接从 HttpRequest 里往外拿值，让业务的 Param 对分页操作无感知。

pubic class Param { // 没有继承 BasePage
    // 业务参数
    // ...
}

public calss Page {
    private Integer pageNum;
    private Integer pageSize;
}

public static Page getPage(HttpRequest request) {
    Integer pageNum = request.getParam("pageNum");
    Integer pageSize = request.getParam("pageSize");

    return new Page(pageNum, pageSize);
}

看到这里，业务参数和分页参数就已经分开了，但还没显现出优势，比如你可能会问，这样往后传递参数的时候，不还多了一个 Page 类型的参数么？从参数的强耦合，变成了接口传参的强耦合了。

// 原有的
List<Result> selectList(Param param);

// 改完的
List<Result> selectList(Param param, Page page);

这样不是更大的麻烦了吗？

解决一个问题，引入另一个问题，扯淡了。。。

莫慌，有解决方法，ThreadLocal 线程共享变量，从 HttpRequest 中拿到 Page 相关的参数之后，不往后传，而是存到 ThreadLocal 中，当有需要的时候再去拿，如下：

public class PageHolder {
    private static final ThreadLocal<Page> LOCAL_PAGE = new ThreadLocal<Page>();

    public static void setPage(Page page) {
        LOCAL_PAGE.set(page);
    }

    public static Page getPage() {
        return LOCAL_PAGE.get();
    }

    public static void clearPage() {
        LOCAL_PAGE.remove();
    }
}

// 保持原有接口不变
List<Result> selectList(Param param);