系列文章目录
前言
一、分页_分析Page分页的业务和sql
现在的网站基本上都有分页
我们可以自己动手去查一下,随便浏览一个有分页的网站,大部分都是有分页的
不分页行不行呢?
1、不分页用户体验很差
如果有300万条数据,这个下拉条基本上看不见了
2、数据量很大的的时候,服务器的压力也是巨大的,甚至直接奔溃卡死
比如上亿条数据,后台数据库要查个几分钟,前台就卡死了
分页必备的元素
然后分析怎么实现
首先肯定是sql
1、分页的sql
注意数据库不同,关键字是所有不同的,比如SqlServer是用between,MySQL是用 limit
用户传过来的只是页码,其它的我们要自行处理,不能让用户去找规律,所以我们必须处理好这个逻辑
如上面的例子
每页显示个数是固定的 5(在没有改动的情况下)
页码又是用户传过来的
所以变化的就是开始下标,开始下标是可以通过已知条件计算出来的,是有规律的
– 所以实际上 开始的标志 经历了 0 5 10 15 20 25 ……这样的变化
– 规律是 啥 (当前页码-1)*页码大小
– 比如第1页(1-1)*5,5
– 比如第2页(2-1)*5,5
– 比如第2页(3-1)*5,5
到这就可以停一停了,我们可以写接口了
但是回过头来我们想一下,分页,我们只要有pageNo就可以解决了吗?
我们写肯定要比百度写得要好一些吧,至少给客户看的东西要多一些,至于用户看不看那就让它自己选择了
&&&不变的的
上一个
下一页
&&& 变量:
当前页:用户传过来的,最后再展示给用户就好,就好像用户点了一碗面,给他是时候告诉他这是您的面
总页数
总记录数
每页显示多少条数据(可以内部我们设置好,也可以开放出来让用户自己设置)
跳转到目标页
这5个变量
每点一次下一页,都要考虑这5个点
所以我们的接口当中需要定义好这5个属性
但是这5个属性有点多,难道1一直传参吗?5个传来传去?
这样不符合我们的一贯风格
所以我们封装一个bean,这种bean我们就称之为业务bean,因为表中,并没有这个表
所以这里我们可以知道,bean分为两种,
一种叫数据bean(数据库中有这张表)
一种叫业务bean(数据库中没有这张表)为了一个业务而去创建的一个bean,我们现在就是为了分页这个业务
考虑一下page为什么加泛型呢?
因为泛型更合理
接下来就是代码实现实现
二、实现Page业务Bean(5个属性值)
有两种思路,正常来说我们放bean包里面,因为它是属于业务bean
但是如果不好理解的话,我们也可以放util里面(工具的意思),
这里的Page.java类,相当于一个分页工具,因为数据库里面并没有这个表
切记,严格来说应该放bean里面(因为它是业务bean)
注意有两个地方需要分页,这两个地方我们的分页尽量要统一,因为后端要为前端服务
所以因为有一个是4条数据,所以我们整体都用4条数据为1页,这样就不用多写冗余代码了,
除非有特殊要求再修改
然后构造器、get set 、toString 一套操作
我们想想这样封装有什么好处
“快递”我们最终是要把它放到域中,这样就一次全部放了,真好
放也方便,取也方便,相当于打了个包,不会太乱
三、计算总页数
,这里需要注意
假如是每页4条数据,如果我有8条数据肯定是8/4=2页,这个没得说,
但是如果我是7条数据是 几页呢7/4=1……3 是1页吗,不,实际上也是2页
如果我是5条数据呢…………………………………… …实际上也是2页
所以我们要用到一个向上取整的函数(C#里面叫做天花板函数)
天花板函数的底层逻辑(如果没有天花板函数我们直接if……else也可以实现天花板函数同样的功能)
判断能不能整除,如果能整除,就取整除后的值
如果不能整除,就取整除后的值+1
因为java这里吗,没有提供天花板函数我们直接使用底层代码
在bean里面修改一下getTotalPageNo
直接返回这个就行了,替换掉原来返回的值
计算总页数是返回getBean还是getBeanList呢?好像都不是
我们发现一个很尴尬的问题,底层没有提供关于聚合函数的方法给我们调用
所以我们需要自己写一个
改成ScalarHandler 并且不需要泛型
以后只要是查询单个值的返回结果,我们就可以调用getSingeValue 方法
然后就是dao的接口,dao的接口我们需不需要返回值呢
然后就是dao的实现类
一个方法里面写两个dao
id是主键,有人会认为写id更靠谱一点
还有些写1的
1其实不好理解,可以像下面这样去理解
总记录数和总页数就出来了
注意,一定是先有记录数再会有总页数,顺序不能颠倒
总结
1、下一篇实现分页
2、一定要写单元测试,测试一下接口,因为很有可能接口没通,我们写半天等于白写