- 系列文章目录
- 18-管理员维护-任务清单——管理员维护的思路
- 19-管理员维护-分页-目标和思路
- 20-管理员维护-分页-引入PageHelper
- 21-管理员维护-分页-AdminMapper
- 22-管理员维护-分页-AdminService
- 23-管理员维护-分页-AdminHandler
- 24-管理员维护-分页-页面显示主体数据
- 造一些测试数据——这样才能测试分页
可以先看一下前端页面，打开前端模型页面
前端页面的数据都是假数据
查询是模糊查询，并且匹配了各个字段，并且，查询出来的结果仍然是分页显示的
所以
我们的分页应该满足两个需求，即可带条件，也可不带条件
因为用户维护和角色维护基本上是一模一样的，所以我们故意用两种知识来做，这样就技术点都学会了
再回顾一下
其实项目进行了这么久，隐约已经发现了这个规律
那就是
开发风格有两种，一种是同步（比如单纯的表单提交），一种是异步（比如用ajax去提交表单）
我们这里这样定位 管理员维护我们使用同步，角色维护我们使用异步（ajax）
所以其实我们写代码，这二者缺一不可
1、你有没有思路
2、编码的技能到不到位
思路
首先我们要想一下，触发分页的入口有哪些地方
查完以后会返回一个List集合
需要注意的是，List是一个接口
因为ER表达式访问不了这个pageNum（页码）ER表达式只认实体类，而现在这个即是实体类又是List
所以我们需要继续往下，其实PageHelper也考虑到这个问题了，所以给了我们很多的可能性，我们可以
封装一个PageInfo
所以最终我们返回的时候要返回PageInfo
所以最终我们的返回是PageInfo，所以这改成PageInfo
如果点进去看看
这里面很多代码是逆向工程自动生成的(逆向工程会自动生成一些常用的比如增删查改的最普通的逻辑代码)
需要注意的是，目前我们这样写实际上是效率不是特别高的，
一般电商网站不这么写，电商网站是很追求性能的极致性的，
他们一般会用另外一个技术，叫 ElasticSearch（采用倒排索引）
这里只是稍微知道一下，具体的优化以后再说
然后就可以写service方法了
那么这里我们的service里面这个接口方法是直接复制过去吗，因为涉及到分页，显然不是直接复制了，那么具体怎么做呢
com.github.pagehelper里面直接就提供了PageInfo implements Serializable
而我们需要考虑的就是，分页我们要放几个参数进去，具体实现先不管
我们只需要输入 关键字、当前页码、每页显示多少条数据即可
总页码数我们需要管吗，根本不需要，pageHelper这个作者已经考虑很周到了，直接自动会帮我计算好
面向接口编程：领导只管给你分配任务，后面你怎么干，它就不管了，你只要干好就行了
分布式开发的时候，很多时候都要面向接口编程
好处就是，只要你这个接口不变，实现类你想怎么变就怎么变，别人用你这个接口并不需要改代码
就好比一个USB接口，你可以接1T的移动硬盘，也可以插2T的移动硬盘，接口是没有变化的，你该怎么插还是怎么插
做人也是一样，如果完全不干扰他人原有的生活，那就是非常好滴
Handler（controller）层需要解决一个问题，那就是
怎么解决有些参数有 、有些参数没有的问题
这里想一下，如果这里我们没有使用@RequestParam注解，会出现什么问题呢，自己试试不使用这个注解出现的问题
特别注意，不要忘记这个模型参数
下一步就是看页面上怎么显示这些数据了
新建如下jsp
注意拷贝的是main标签
可能不好复制，不知道那块结束的，所以我们可以这样
假数据只留一条（用来参考），其它的全部删掉
写代码是一件非常严谨的事情，打错一个单词一个空格都不行，下面是我们需要注意的容易出错的地方
因为目前还没有做好页码功能，所以目前是这样返回第几页的
这样就说明没有问题了
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）