回显
1.根据id进行查询
2.修改数据
点击修改，实质上id传过了，会先进行id的查询，就造成了数据的回显
与分页不同，分页是两个结果的判断，回显是先后操作
分页步骤
1.接收参数controller（返回pageresult结果）
2.serviceimpl
步骤
2.1 使用pagehelper进行分页（传入controller接受的 page，pagesize）
2.2 调用mapper层方法（分页查询本质上返回的是一个实体类的集合）
2.3 强转为page类型（方便传递 total result（查询的结果））
2.4 传回 pageresult的对象（把 total result传入）
3.调用mapper层方法
注入
controller
service实现类
mapper接口
aop理解如何获取方法，操作步骤
1.定义注解
2.把注解放在要进行aop的类
3.通过around进行切入
4.如何获取方法的信息（详细。所有）；
5.使用around时，必须使用proceed显示调用执行，否则不会生效
图片上传
注解只能使用@RequestParam 或 @ModelAttribute（无论请求参数在哪里）
- 文件上传必须用
@RequestParam或@ModelAttribute，因为它们支持multipart/form-data。 - 如果需要同时处理 JSON 数据，有两种方案：
- 将 JSON 作为普通表单字段（字符串）传递，手动解析（如示例 2）。
- 分两次请求：先上传文件，再提交 JSON 数据。
分页
- 正常返回结果（调用servce）
- service 层返回结果是pageResult（自定义，不用hutool）
2.1先使用pagehelp进行数据统计，后面调用mapper获得所要展示的产品的集合
2.2把得到集合用page转化
2.3 把返回total和rows
3.mapper层查询，要判断（根据复选框）
示例
@Override public PageResult FenYeQuery(DishPageQueryDTO dishPageQueryDTO) { Page<Object> objects = PageHelper.startPage(dishPageQueryDTO.getPage(), dishPageQueryDTO.getPageSize()); List<Dish> dishes = dishMapper.fenYeQuery(dishPageQueryDTO); Page<Dish> dishPage=(Page<Dish>) dishes; return new PageResult(dishPage.getTotal(),dishPage.getResult()); }
如何获取自增id
示例： 员工表中包括经历表（员工表是自增id） 要在插入员工的语句中添加useGeneratedKeys="true" keyProperty="id"，后面才可以直接获取自增的id
通过一个表的id去查询另一个表是否有匹配的数据（一般是e_id）
方法1：直接返回结果(就是用包装类型integer接收)
要先判断是否为null，再判断是否大于0（e_id都是大于0的）
方式2：使用统计（用count）(优解)
count(*) 的特性：SQL 的 count(*) 函数会统计符合条件的记录数，无论是否存在匹配的记录，结果都至少为 0，不会返回 null。
原因：
- 当有匹配记录时：
setmeal_id是具体的整数（如 1、2），MyBatis 会将其映射为Integer对象（值为 1、2 等）。 - 当无匹配记录时：查询结果是空集（没有任何行），此时 MyBatis 无法获取到
setmeal_id的值，会将返回值映射为null（因为没有数据可填充）。
关键点：数据库中 “没有查询到数据” 和 “查询到的值为 0” 是完全不同的情况：
- 前者是 “无结果”，映射为
null； - 后者是 “有结果但值为 0”，映射为
Integer 0。
针对更新操作
单表
多表（先回显此时所有的数据已经准备好，如果要修改某一项，那么其他的数据会再传输一份）
比如： 信息是： a b 要修改b->c 第一步回显 显示出 a b 第二步 在前端修改 b->c 最终结果 是 a c 然后点击修改传递的是全部的数据，不是只传递修改的部分
单表更新 vs 多表更新的核心差异
场景 |
单表更新（如只改套餐名称） |
多表更新（如改套餐名称 + 改关联餐品） |
涉及表 |
仅 1 个表（如套餐表） |
至少 2 个表（套餐表 + 套餐 - 餐品关联表） |
核心操作 |
直接根据主键更新字段（如 ） |
1. 更新主表（套餐表）字段； |
复杂度 |
低（只需保证单条记录正确） |
高（需保证主表和关联表数据 “匹配”，比如关联表不能出现主表不存在的套餐 ID） |
一致性要求 |
单表内数据正确即可 |
必须保证 “主表改了，关联表也同步改”，否则会出现 “套餐存在但关联餐品丢了” 或 “关联餐品指向不存在的套餐” 等问题 |
service 的逻辑拆解如下，重点看 “主表” 和 “关联表” 的不同处理方式：
- 主表的信息是 “单条独立记录”，改的时候直接改对应字段就行；
- 关联表的信息是 “一堆关系的集合”，改的时候很难精确比对每一条关系，所以用 “全删全插” 的方式保证结果正确，还省事儿。
