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

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

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言

我又来开新坑了，最近手头的项目是对一个旧的管理系统做服务化重构，这个管理系统是在 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