RESTful批量删除接口设计与MyBatis-Plus实现

1. 菜品批量删除接口设计与实现解析

在餐饮管理系统的开发过程中，菜品管理模块的删除功能是一个看似简单但实际需要考虑多种业务场景的核心功能。本文将详细拆解一个支持批量删除的菜品接口实现方案，包含完整的RESTful设计、参数处理、业务校验和数据库操作全流程。

1.1 接口设计规范

1.1.1 RESTful风格实现

采用DELETE方法作为HTTP请求类型，严格遵循RESTful架构风格的设计原则。与常见的POST方法携带删除参数不同，DELETE方法在语义上更准确地表达了删除操作意图，使API设计更加规范和专业。

接口路径设计为/dish，保持资源导向的命名方式。这种设计使得：

• 资源定位清晰（/dish表示菜品资源集合）
• 操作类型明确（DELETE方法表示删除）
• 扩展性强（未来可轻松添加其他操作）

1.1.2 批量删除参数设计

采用Query参数传递要删除的菜品ID列表，参数名为ids，多个ID之间用英文逗号分隔。例如：

code复制DELETE /dish?ids=1,2,3,4

这种设计相比JSON body更符合HTTP规范，具有以下优势：

1. 删除操作通常不需要复杂数据结构，简单参数即可满足
2. URL参数更易于调试和日志记录
3. 符合RESTful对简单查询操作的约定
4. 天然支持GET/DELETE等方法的参数传递

1.2 请求与响应结构

1.2.1 请求参数处理

Spring MVC通过@RequestParam注解自动处理URL参数。当参数定义为List<Long>类型时，框架会智能完成：

1. 字符串分割：将"1,2,3"拆分为["1","2","3"]
2. 类型转换：将字符串元素转换为Long类型
3. 集合封装：最终生成List<Long>对象

这种处理方式极大简化了开发工作，避免了手动解析字符串的繁琐操作。在实际项目中，建议：

• 明确参数名称（如ids而非模糊的idList）
• 使用基础类型集合（Long而非复杂对象）
• 保持参数命名风格一致（全小写+复数形式）

1.2.2 统一响应格式

采用行业通用的三层响应结构：

json复制{
  "code": 200,
  "data": null,
  "msg": "删除成功"
}

这种结构化响应具有以下优点：

• 状态码(code)：明确业务操作结果（如200成功，500失败）
• 数据载体(data)：实际返回的业务数据（删除操作通常为null）
• 提示信息(msg)：人类可读的操作结果说明

提示：在实际项目中，建议使用枚举定义标准状态码，避免魔法数字的出现。

2. 业务逻辑实现细节

2.1 Controller层实现

2.1.1 方法签名设计

java复制@DeleteMapping
public Result<String> delete(@RequestParam List<Long> ids) {
    dishService.deleteBatch(ids);
    return Result.success();
}

关键设计要点：

1. 使用@DeleteMapping明确HTTP方法映射
2. 方法参数直接使用List<Long>接收批量ID
3. 返回统一的Result包装对象
4. 业务逻辑委托给Service层处理

2.1.2 异常处理机制

在实际开发中，Controller还应包含基本的异常捕获：

java复制try {
    dishService.deleteBatch(ids);
    return Result.success();
} catch (BusinessException e) {
    return Result.error(e.getCode(), e.getMessage());
} catch (Exception e) {
    log.error("删除菜品异常", e);
    return Result.error("系统异常");
}

2.2 Service层实现

2.2.1 服务接口定义

java复制public interface DishService {
    void deleteBatch(List<Long> ids);
}

接口设计原则：

• 方法名明确表达批量操作意图（deleteBatch）
• 参数使用集合类型而非数组（更符合Java习惯）
• 返回void（删除操作通常无需返回数据）

2.2.2 业务校验逻辑

实现类中包含两个核心校验：

校验一：菜品是否在售

java复制LambdaQueryWrapper<Dish> queryWrapper = new LambdaQueryWrapper<>();
queryWrapper.in(Dish::getId, ids).eq(Dish::getStatus, 1);
long count = dishMapper.selectCount(queryWrapper);
if (count > 0) {
    throw new BusinessException("存在启售菜品，无法删除");
}

校验二：菜品是否被套餐关联

java复制LambdaQueryWrapper<SetmealDish> setmealDishQueryWrapper = new LambdaQueryWrapper<>();
setmealDishQueryWrapper.in(SetmealDish::getDishId, ids);
long setmealCount = setmealDishMapper.selectCount(setmealDishQueryWrapper);
if (setmealCount > 0) {
    throw new BusinessException("菜品已被套餐关联，无法删除");
}

注意：这两个校验顺序不可颠倒，应先检查在售状态再检查关联关系，因为关联检查需要额外查询。

2.2.3 实际删除操作

通过事务保证数据一致性：

java复制@Transactional
public void deleteBatch(List<Long> ids) {
    // 校验逻辑...
    
    // 删除菜品
    dishMapper.deleteBatchIds(ids);
    
    // 删除关联口味
    LambdaQueryWrapper<DishFlavor> flavorQueryWrapper = new LambdaQueryWrapper<>();
    flavorQueryWrapper.in(DishFlavor::getDishId, ids);
    dishFlavorMapper.delete(flavorQueryWrapper);
}

事务处理要点：

1. 使用@Transactional注解声明事务
2. 先执行所有校验逻辑再操作数据库
3. 保持操作顺序：先删主表再删关联表
4. 批量操作使用MyBatis-Plus提供的批量方法

3. 数据持久层实现

3.1 MyBatis-Plus 批量操作

3.1.1 菜品表删除

java复制dishMapper.deleteBatchIds(ids);

底层实际执行的SQL：

sql复制DELETE FROM dish WHERE id IN (?, ?, ?)

3.1.2 口味表关联删除

java复制LambdaQueryWrapper<DishFlavor> flavorQueryWrapper = new LambdaQueryWrapper<>();
flavorQueryWrapper.in(DishFlavor::getDishId, ids);
dishFlavorMapper.delete(flavorQueryWrapper);

生成的SQL：

sql复制DELETE FROM dish_flavor WHERE dish_id IN (?, ?, ?)

3.2 查询优化技巧

3.2.1 状态检查查询

java复制@Select("SELECT COUNT(*) FROM dish WHERE id IN (#{ids}) AND status = 1")
Long countOnSaleByIds(@Param("ids") List<Long> ids);

使用注解SQL提高可读性，IN语句处理集合参数时需要注意：

• MyBatis会自动处理List参数
• 大型集合应考虑分批次查询
• 必要时添加索引优化

3.2.2 关联关系查询

java复制@Select("SELECT COUNT(*) FROM setmeal_dish WHERE dish_id IN (#{ids})")
Long countRelatedSetmeals(@Param("ids") List<Long> ids);

关联查询优化建议：

1. 确保dish_id字段有索引
2. 大数量级时考虑分页查询
3. 可添加缓存减少重复查询

4. 实战经验与问题排查

4.1 常见问题解决方案

问题一：参数格式错误

• 现象：请求ids=1,2,a导致400错误
• 解决：前端进行参数校验，后端添加全局异常处理

问题二：事务超时

• 现象：批量删除大量数据时事务超时
• 解决：
  1. 分批处理（每100条一个批次）
  2. 调整事务超时时间
  3. 优化SQL性能

问题三：并发删除冲突

• 现象：同时删除同一菜品导致数据不一致
• 解决：
  1. 添加乐观锁版本控制
  2. 关键操作加分布式锁
  3. 实现软删除模式

4.2 性能优化建议

1. 批量操作：使用MyBatis-Plus提供的批量方法而非循环单条删除
2. 索引优化：确保dish_id、status等查询字段有适当索引
3. 异步处理：对大型删除操作可考虑异步队列处理
4. 缓存一致：删除后及时清理相关缓存（如菜品详情缓存）

4.3 扩展思考

软删除实现方案：

java复制@TableLogic
private Integer deleted;

使用@TableLogic注解实现逻辑删除优势：

• 保留数据历史记录
• 避免物理删除的关联问题
• 便于数据恢复和审计

接口安全增强：

1. 添加权限校验（如@PreAuthorize）
2. 限制批量操作最大数量
3. 操作日志记录

在实际开发中，我通常会为这类关键操作添加详细的日志记录，包括操作人、时间、影响数据量等信息。这既便于问题追踪，也符合审计要求。同时，对于批量操作的规模会做限制（如单次不超过100条），防止误操作导致大规模数据丢失。