【服务化重构日记1】菜单角色用户等系统表单独成库之后以前join操作的数据权限怎么处理？_params instanceof basedatascopeentity-CSDN博客

本文链接：https://blog.csdn.net/Sunsscode/article/details/116031147

在服务化重构过程中，面对用户角色权限管理，如何处理数据权限成为挑战。文章探讨了通过切面重写SQL、冗余数据避免跨库JOIN、不同客户端接口定制三种策略，分析其优缺点，并分享了作者在处理签到记录查询权限时的思考，引发对服务化重构正确性的反思。

摘要由CSDN通过智能技术生成

前言

我又来开新坑了，最近手头的项目是对一个旧的管理系统做服务化重构，这个管理系统是在 jeesite2.x 上二开的，除了jeesite本身带着的用户权限等的这一套权限菜单数据权限范围的管理外还有业务层面的教学模块、进销存模块、分销模块、资产薪酬模块、报表中心模块等。

这一系列的文章将记录我自己在重构过程中遇到的阻碍、问题和对应的解决策略。

服务化重构基于的二开框架是若依微服务版。

问题引入

比方说有这样子的需求，学生、老师、门店教务管理员、多门店教务管理员、机构教务管理员，共五类角色，要查看学生上课签到记录：

对于学生来说，只能看见自己的签到记录
对于老师来说，只能看见自己上的课的学生的签到记录
对于门店教务管理员来说，能看见所管理门店的所有签到记录
对于多门店教务管理员来说，能看见机构所属的分配给他的门店的签到记录
机构教务管理员，能看见机构的所有签到数据

对于一个签到表来说，简化考虑，它必然会包含下面这些字段：

CREATE TABLE `student_course_check_record`  (
  `id` bigint(20) NOT NULL COMMENT '主键',
  `student_id` bigint(20) NOT NULL COMMENT '签到学生id',
  `course_id` bigint(20) NULL COMMENT '签到课程id',
  `create_by` bigint(20) NULL COMMENT '创建人',
  PRIMARY KEY (`id`)
);

创建人不一定是学生本人，有可能是老师代签的。

通过切面来重写SQL查询语句

通过注解+切面方式应该是最多的控制数据权限和范围的方式，一般配置两个字段一个是 user 表，还有一个是部门表。

比如下面这个例子：

@Override
@DataScope(deptAlias = "d", userAlias = "u")
public List<SysUser> selectUserList(SysUser user) {
	return userMapper.selectUserList(user);
}

在查询用户list的方法上添加 @DataScope注解，这里分别配置了部门表和用户表的别名。

这是定义的注解：

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface DataScope {
    /**
     * 部门表的别名
     */
    public String deptAlias() default "";

    /**
     * 用户表的别名
     */
    public String userAlias() default "";
}

再来看切面类，主要是切入点和doBefore两个操作：

// 配置织入点
@Pointcut("@annotation(com.ruoyi.common.datascope.annotation.DataScope)")
public void dataScopePointCut() {}

@Before("dataScopePointCut()")
public void doBefore(JoinPoint point) throws Throwable {
	handleDataScope(point);
}

handleDataScope() 就是进行sql添加的方法，具体是这样子的：

protected void handleDataScope(final JoinPoint joinPoint) {
        // 获得注解
	DataScope controllerDataScope = getAnnotationLog(joinPoint);
	if (controllerDataScope == null) {
    	return;
    }
    // 获取当前的用户
    LoginUser loginUser = tokenService.getLoginUser();
    if (StringUtils.isNotNull(loginUser)) {
       SysUser currentUser = loginUser.getSysUser();
       // 如果是超级管理员，则不过滤数据
       if (StringUtils.isNotNull(currentUser) && !currentUser.isAdmin()) {
            dataScopeFilter(joinPoint, currentUser, controllerDataScope.deptAlias(),
                    controllerDataScope.userAlias());
        }
    }
}

具体的组装sql的内容在dataScopeFilter()方法中，会根据用户的角色和配置的角色能看到的数据范围结合部门表、用户表进行过滤。

最后如果这个入参的Entity是继承BaseEntity的，那么这段sql会被保存在params.dataScope字段里面，params是一个HashMap：

if (StringUtils.isNotBlank(sqlString.toString())) {
	Object params = joinPoint.getArgs()[0];
    if (StringUtils.isNotNull(params) && params instanceof BaseEntity) {
		BaseEntity baseEntity = (BaseEntity) params;
		baseEntity.getParams().put(DATA_SCOPE, " AND (" + sqlString.substring(4) + ")");
    }
}

最后到使用阶段，会在MyBatis中用 ${params.dataScope} 的方式被使用：

<select id="selectUserList" parameterType="SysUser" resultMap="SysUserResult">
	select u.user_id, u.dept_id, u.nick_name, u.user_name, u.email, u.avatar, u.phonenumber, u.password, u.sex, u.status, u.del_flag, u.login_ip, u.login_date, u.create_by, u.create_time, u.remark, d.dept_name, d.leader from sys_user u
		left join sys_dept d on u.dept_id = d.dept_id
		where u.del_flag = '0'
	<if test="userName != null and userName != ''">
		AND u.user_name like concat('%', #{userName}, '%')
	</if>
	<!-- 其它查询条件 -->
	<!-- 数据范围过滤 -->
	${params.dataScope}
</select>

这种方式的优点：

全局做了处理，数据范围和权限关系非常清晰
可以比较灵活地支持不同角色和不同的数据范围

这种方式的缺点：

必然存在join和子查询
如果做了分库，用户相关的表被单独成库了，那么会面临跨库join

多份冗余

为了避免跨库join，将用户部分相关的表全部都放在业务库里面，这样子做join的时候只会出现本地库的join.

这毫无疑问会引入一致性的问题，用户表更新还是比较频繁的。

而且这样子做很丑陋，一点美感都有。

不同的客户端不同的接口

我们抛弃用切面重写SQL的思路，转而对接口进行定制。

不同的角色有时候会有不同的客户端，比如说学生使用的、教师使用的、管理人员使用的可能会是不一样的。

那么就可以控制不同的角色请求不同的接口，那上面查询签到表的情况举例：

学生端请求的接口是：GET /checkRecord/self/{courseId}

studentId在查询时后端根据currentUser会强制入参，courseId是可选的参数，courseId也可以是作为queryParams来入参的，不一定是restful样式的。

教师端请求的接口是：GET /checkRecord/teacher/{courseId}

这里的查询逻辑就是查询教师教授的课程的签到情况：

...course_id in (select course_id from teacher_course_mapper where teacher_id = #{currentUser.id})

同样courseId是可以入参的，如果入参了那就是与逻辑.

对于相关管理员来说，又是另一个接口，之前的字段里面只有create_by，通过create_by我们就可以找到创建者所属的门店或者机构，在这个环境下，我们还需要引入一个新的字段shop_id，这一字段标识这条数据被创建时用户所登录的门店，它不一定是冗余的，因为一个机构管理员它可以选择登录对应的门店。

这个方案的优点：