分页设计+数据库进阶

分页设计+数据库进阶(1.23)

一、分页逻辑

1.逻辑图

2.有关curPage的值的来源：

前端发送请求--->servlet接收请求，初始化curPage=1--->service层接收curPage，封装到PageVo (PageVo 类虽然有 private int curPage=1 的默认值，但这里会被 setCurPage(curPage) 覆盖（即使值也是 1，逻辑上是 Servlet 的默认值生效）；调用 setData() 时，PageVo 会校验 curPage（1≥1 且 1≤总页数），然后截取第 1 页的数据（每页 5 条）。--->Servlet 将 PageVo 存入 request，转发到 JSP--->JSP 从 request 中取出 PageVo，把 curPage 赋值给隐藏域 --->用户点击 “下一页 / 上一页 / 尾页”（分页操作，传递 curPage）--->前端 JS 修改 curPage，提交表单(携带了 curPage=2 的参数) 相当于重新访问/book,不同的request对象--->

Servlet 接收并解析 curPage--->重复场景 1 的步骤 3~5

3.为什么要在PageVo设置curPage初始值为1？

(1) int 类型的默认值陷阱

如果不手动设curPage=1，int 类型的成员变量默认值是0。假设出现以下场景：

- 开发时疏忽：某个业务模块调用 PageVo 时，忘了写bookPageVo.setCurPage(curPage)；

- 代码重构：删除了 Service 层的setCurPage代码，但没发现；

此时 PageVo 的curPage会是默认值0，后续分页计算会直接出错：

(2) 初始值 1 的核心作用

把初始值设为 1，即使外部忘了设置 curPage，PageVo 的分页逻辑也能 “保底运行”（默认查第 1 页），而不是直接崩溃 —— 这是给 PageVo 类加的第一层兜底。

4.为什么要写那两个 if 校验？

(1) 外部调用者可能 “没处理合法性”

PageVo 是通用分页工具类，无法保证所有调用者都像 BookServlet 一样严谨

(2)前端分页操作的 “极端值” 需要兜底

比如你代码里的 “尾页” 逻辑：JS 直接把 curPage 设为 999，Servlet 接收后会直接传给 PageVo—— 如果没有if(curPage>totalPage)，PageVo 会按 999 页去截取数据（结果是空列表），而有了这个校验，会自动把 999 改成总页数，保证用户能正确跳转到最后一页。)

(3) 符合 “封装性” 原则

一个健壮的工具类（PageVo），应该自己保证自身数据的合法性，而不是把 “校验责任” 推给外部调用者：

二、JSP 并不是直接展示给浏览器的最终载体，浏览器才是最终渲染、展示页面的载体**；

完整的 “JSP → 浏览器展示” 流程：

Servlet 完成逻辑，转发请求到 JSP（服务器内部）--->服务器编译、执行 JSP，生成纯 HTML 代码（核心）--->服务器把 HTML 发送给浏览器（HTTP 响应）--->浏览器渲染 HTML，展示最终页面（最终载体）

三、request 的 AttributeMap 数据，响应后还存在吗？

完全不存在了，request.getAttributeMap()（本质是request对象的属性集合）是紧紧绑定在request对象生命周期上的

四、新增 / 删除方法都用 "msg" 作为 key 存提示，因为 request 不同，所以同名无所谓？

完全无所谓，而且这是推荐的做法。

• 当你发起 “新增请求” 时：服务器创建request1，request1的 AttributeMap 里msg="添加成功"；
• 当你发起 “删除请求” 时：服务器创建request2，request2的 AttributeMap 里msg="删除成功"；
• 这两个msg属于不同的request对象，就像两个不同的抽屉里都有一个叫 “msg” 的文件，互相看不到、不冲突。

额外好处：

你可以在 JSP 里统一用同一个方式读取msg（比如<%= request.getAttribute("msg") %>），不用为新增写msg_add、删除写msg_delete，简化前端展示逻辑。

补充：容易踩坑的 “同名 key” 场景

// 同一个request里，先存A，再存B，最终msg=B
request.setAttribute("msg", "添加成功");
request.setAttribute("msg", "参数错误");