前面完成了后台系统的员工管理功能开发,在新增员工时需要手动设置数据创建时间,数据修改时间,创建人等等,这些属于功能字段,应该设置自动添加
MyBatisPlus公共字段自动填充,也就是在插入或者更新的时候为指定字段赋予指定的值,可以对一些字段进行处理,避免了重复代码
实现步骤:
在实体类的属性上加入@TableFied注解指定自动填充的策略
按照框架要求编写元数据对象处理器,在此类中统一为公共字段赋值,此类需要实现MetaObjectHandler接口
/**
* 自定义元数据对象处理器
*/
@Component
@Slf4j
public class MyMetaObjectHandler implements MetaObjectHandler {
/**
* 插入操作,自动填充
* @param metaObject
*/
@Override
public void insertFill(MetaObject metaObject) {
log.info("公共字段自动填充[insert].......");
log.info(metaObject.toString());
metaObject.setValue("createTime", LocalDateTime.now());
metaObject.setValue("updateTime",LocalDateTime.now());
metaObject.setValue("createUser",BaseContext.getCurrentId() );
metaObject.setValue("updateUser", BaseContext.getCurrentId());
}
/**
* 更新操作,自动填充
* @param metaObject
*/
@Override
public void updateFill(MetaObject metaObject) {
log.info("公共字段自动填充[update].......");
log.info(metaObject.toString());
long id = Thread.currentThread().getId();
log.info("线程id为:{}",id);
metaObject.setValue("updateTime",LocalDateTime.now());
metaObject.setValue("updateUser", BaseContext.getCurrentId());
}
}
自动填充时间,修改人信息成功
什么是ThreadLocal?
ThreadLocal并不是一个Thread,而是Thread的局部变量,当使用ThreadLocal维护变量时,ThreadLocal为每个使用该变量的线程提供独立的变量副本,所以每一个线程都可以独立的改变自己的副本,而不会影响其他线程所对应的副本。ThreadLocal为每个线程提供单独一份存储空间,具有线程隔离的效果,只有在线程内才能获取到对应的值,线程外则不能访问。
ThreadLocal常用方法:
public void set(T value) 设置当前线程的线程局部变量的值
public T get() 返回当前线程所对应的线程局部变量的值
我们可以在LoginCheckFilter的dofilter方法中获取当前登陆用户的id,并调用ThreadLocal的set方法来设置当前线程的线程局部变量的值(用户id),然后再MyMetaObjectHandler的updateFill中调用ThreadLocal的set方法来获取当前线程所对应的线程局部变量的值
实现步骤:
编写BaseContext工具类,基于ThreadLocal封装的工具类
/**
* 基于ThreadLocal封装的工具类
*/
public class BaseContext {
private static ThreadLocal<Long> threadLocal=new ThreadLocal<>();
public static void setCurrentId(Long id){
threadLocal.set(id);
}
public static Long getCurrentId(){
return threadLocal.get();
}
}
LoginCheckFilter的dofilter方法中调用BaseContext设置当前登录用户的id
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BTHscOCP-1655612366452)(C:\Users\12044\Documents\实战项目\瑞吉外卖项目\瑞吉-image-19.png)]
在MyMetaObjectHandler的方法中调用BaseContext获取登录用户的id
metaObject.setValue(“updateUser”, BaseContext.getCurrentId());
后台系统中可以管理分类信息,分类包括两种类型,分别是菜品分类和套餐分类。当我们在后台系统中添加菜品时需要选择一个菜品分类,当我们在后台系统中添加一个套餐时需选择一个套餐分类,在移动端也会按照菜品分类和套餐分类来展示对应的菜品和套餐
新增分类,其实就是将我们新增窗口录入的分类数据插入到category表
在开发业务前,将需要用到的类和接口基本结构创建好:
执行流程:
添加分类功能成功
以分页的信息展示菜品信息
跟前面分页查询用户列表功能相似,就不写代码了
没什么问题的,简单的查询功能,加了升序排序
//添加排序条件
queryWrapper.orderByAsc(Category::getSort);
在分类管理列表中,可以对某个分类进行删除操作,注意,当分类关联了菜品或者套餐时,此分类不允许删除
执行流程:
@DeleteMapping
public R<String> delete(Long ids){
log.info("删除分类,id为:{}",ids);
categoryService.removeById(ids);
return R.success("分类删除成功");
}
虽然完成了根据id删除分类的功能,但是并没有检查删除的分类是否关联菜品或者套餐,所以我们需要进行功能完善
要完善分类删除功能,需要先准备基础的类和接口:
需要编写一个类接收处理这个判断异常
/**
* 自定义业务异常类
*/
public class CustomException extends RuntimeException{
public CustomException(String message){
super(message);
}
}
在全局异常处理中调用此异常
/**
* 异常处理方法
* @return
*/
@ExceptionHandler(CustomException.class)
public R<String> exceptionHandler(CustomException ex){
log.error(ex.getMessage());
return R.error(ex.getMessage());
}
修改删除功能,在删除的基础上加上判断
/**
* 根据id删除分类,删除前进行判断
* @param ids
*/
@Override
public void remove(Long ids) {
LambdaQueryWrapper<Dish> dishLambdaQueryWrapper=new LambdaQueryWrapper<>();
//添加查询条件,根据分类id进行查询
dishLambdaQueryWrapper.eq(Dish::getCategoryId,ids);
long count1 = dishService.count(dishLambdaQueryWrapper);
//查询当前分类是否关联了菜品,如果已经关联,抛出业务异常
if (count1>0){
//已经关联菜品,抛出业务异常
throw new CustomException("当前分类下关联了菜品,不能删除");
}
//查询当前分类是否关联了套餐,如果已经关联,抛出业务异常
LambdaQueryWrapper<Setmeal> setmealLambdaQueryWrapper = new LambdaQueryWrapper<>();
//添加查询条件,根据分类id进行查询
setmealLambdaQueryWrapper.eq(Setmeal::getCategoryId,ids);
long count2 = setmealService.count(setmealLambdaQueryWrapper);
if(count2>0){
//已经关联套餐,抛出业务异常
throw new CustomException("当前分类下关联了套餐,不能删除");
}
//正常删除
super.removeById(ids);
}
/**
* 根据id修改分类信息
* @param category
* @return
*/
@PutMapping
public R<String> update(@RequestBody Category category){
log.info("修改分类信息:{}",category);
categoryService.updateById(category);
return R.success("修改分类信息成功");
}