若依二开:带你优化数据权限模块（若依框架数据权限）

今天继续和大家分享，基于若依框架的二次开发以及优化，今天的主要目标是对数据权限这一个模块进行改进。数据权限不同于操作权限，它是强依赖数据库的，就是说需要SQL的支持，不管怎么实现都离不开SQL的改写。按照惯例，要要优化改造一个已有的功能，首先必须先搞清楚原有功能逻辑以及实现原理。若依中实现数据权限的大概流程如下：

1、通过界面角色管理，给角色赋予数据权限，一个角色只能设置一种数据数权限

2、数据权限分5种类型，分别是全部，自定义、部门、部门及以下、个人数据

3、通过AOP加自定义注解DataScope 对service接口进行拦截，根据当前用户角色进行SQL拼装，注入数据表别名和用户部门，角色数据

4、将拼装好的SQL注入到BaseEntity对象中，这个对象有一个Map类型的属params性，用来保存SQL，查询实体都继承BaseEntity实体

5、mybatis的xml文件获取BaseEntity的params，和业务查询SQL拼接在一起

整体来看，这个实现方式没有什么大问题，基于对代码的更高要求，觉得这个设计上有那么一点点改造的空间，其不足主要以下几个地方：

1、XML中都需要加上数据权限的SQL拼接逻辑，业务查询和数据权限查询耦合一起

2、查询参数必须继承BaseEntity实体，这是强耦合

3、数据权限强依赖SQL，属于ORM层，在ORM框架中进行SQL拦截改写会更合理

4、SQL拼接逻辑主体依据角色，会让SQL重复度过高，因为不同角色有可能同一种数据权限，最理想情况下都是一种数据权限，但是仍然需要拼接多次SQL

按如图的方式，如果某个用户拥有 110,111,112,113 四个角色ID，每个角色都有自定义部门权限，则最后组装出来的SQL如下：

OR d.dept_id IN ( SELECT dept_id FROM sys_role_dept WHERE role_id = 110 )

OR d.dept_id IN ( SELECT dept_id FROM sys_role_dept WHERE role_id = 111 )

OR d.dept_id IN ( SELECT dept_id FROM sys_role_dept WHERE role_id = 112 )

OR d.dept_id IN ( SELECT dept_id FROM sys_role_dept WHERE role_id = 113 )

从语句可以看出，变化的只是角色ID，如果角色越多，则这个SQL重复率越高，虽然功能上没问题，但是SQL的维护和性能感觉上不是最优。

基于以上几个问题，笔者按照自己的思路做一次整体的改进优化，其具体思路如下：

1、直接基于mybaitis拦截器实现，在ORM层拦截mapper在分页插件前改写SQL，让业务代码无侵入性

2、拼接SQL逻辑依据数据权限而不是角色，降低SQL重复率，提高查询性能和维护性

3、将DataScope从service接口迁移到Mapper接口

因为我之前已经将若依框架升级到mybatis-plus，所以这里我的拦截器是实现mybatis-plus拦截器而不是mybatis原生拦截器，至于这两种拦截器有什么区别，下一期我详细介绍。这个拦截器的部分代码如下：

public class DataScopeInnerInterceptor implements InnerInterceptor {
    private final Logger logger = LoggerFactory.getLogger(getClass());
    @Override
    public void beforeQuery(Executor executor, MappedStatement statement, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException {
        try {
            DataScope dataScope = getDataScope(statement);
            //没有注解直接放行,可根据情况补充更多的业务逻辑
            if (dataScope == null) {
                return;
            }

            LoginUser loginUser = SecurityUtils.getLoginUser();
            if (com.ruoyi.common.utils.StringUtils.isNotNull(loginUser)) {
                SysUser currentUser = loginUser.getUser();
                // 如果是超级管理员，则不过滤数据
                if (com.ruoyi.common.utils.StringUtils.isNotNull(currentUser) && currentUser.isAdmin()) {
                    return;
                }
            }
            logger.info("执行数据权限拦截器前:{}", boundSql.getSql());
            String sql = modifyOrgSql(loginUser.getUser(), boundSql.getSql(), dataScope, false);
            logger.info("执行数据权限拦截器后:{}", sql);
            // 包装sql后，重置到invocation中
            MappedStatement newStatement = newMappedStatement(statement, new BoundSqlSqlSource(boundSql));
            MetaObject msObject = MetaObject.forObject(newStatement, new DefaultObjectFactory(), new DefaultObjectWrapperFactory(), new DefaultReflectorFactory());
            msObject.setValue("sqlSource.boundSql.sql", sql);
            statement = newStatement;

        } catch (Exception e) {
            logger.error("{}", e.getMessage());
        }
    }

这里需要实现
com.baomidou.mybatisplus.extension.plugins.inner.InnerInterceptor接口，这个是mybatis-plus基于mybatis做了进一步封装的自己定义的内部拦截器，它主要有七个方法，它的拦截方法比原生mybatis更容易理解和使用。其中 beforeQuery 就是在执行sql之前拦截，所以我这里就实现这个方法，拿到SQL后进行重写就可以自动注入数据权限相关的查询逻辑。modifyOrgSql 就是具体的重写SQL的实现，代码如下：

    private final String modifyOrgSql(SysUser user, String orgSQql, DataScope dataScope, boolean innerCount) throws JSQLParserException {
        CCJSqlParserManager parserManager = new CCJSqlParserManager();
        //重新解析SQL语句
        Select select = (Select) parserManager.parse(new StringReader(orgSQql));
        PlainSelect plain = (PlainSelect) select.getSelectBody();
        if (innerCount) {
            SubSelect subSelect = (SubSelect) plain.getFromItem();
            plain = (PlainSelect) subSelect.getSelectBody();
        }
        String dataScopeSql = getDataScropeSql(user, dataScope);
        if (StringUtils.isNotBlank(dataScopeSql)) {
            Expression where = plain.getWhere();
            if (where == null) {
                //如果没有where条件，则直接添加
                plain.setWhere(CCJSqlParserUtil.parseCondExpression(dataScopeSql));
            } else {
                //如果已经有where 则将wehre 加上拼接后的sql表达式
                plain.setWhere(new AndExpression(where, CCJSqlParserUtil.parseCondExpression(dataScopeSql)));
            }

        }
        return select.toString();
    }

上面代码中的getDataScropeSql 就是重写了若依在AOP拦截器里面的组装数据权限SQL的方法。

    private final String getDataScropeSql(SysUser user, DataScope dataScope) {
       //部门表别名
        String deptAlias = dataScope.deptAlias();
      //用户表别名
        String userAlias = dataScope.userAlias();
        final StringBuilder addWhere = new StringBuilder();
      // 数据权限
        Set dataScopeSet = Sets.newHashSet();
      //将所有角色id用逗号连接
        StringBuilder roleIds = new StringBuilder(user.getRoles().size() * user.getRoles().size());
        //遍历所有角色,过滤当前用户的数据权限
        user.getRoles().forEach(role -> {
            if (roleIds.length() > 0) {
                roleIds.append(",");
            }
            roleIds.append(String.valueOf(role.getRoleId()));
            dataScopeSet.add(role.getDataScope());
        });
       //如果包含了所有权限，则不需要再组装数据权限SQL
        if (!dataScopeSet.contains(DATA_SCOPE_ALL)) {
            dataScopeSet.forEach(ds -> {
                switch (ds) {
                    case DATA_SCOPE_CUSTOM:
                        if (roleIds.length() > 0) {
                            addWhere.append(com.ruoyi.common.utils.StringUtils.format(
                                    " OR {}.dept_id IN ( SELECT dept_id FROM sys_role_dept WHERE role_id in ({}) ) ", deptAlias, roleIds.toString()));
                        }
                        break;
                    case DATA_SCOPE_DEPT:
                        addWhere.append(com.ruoyi.common.utils.StringUtils.format(" OR {}.dept_id = {} ", deptAlias, user.getDeptId()));
                        break;
                    case DATA_SCOPE_DEPT_AND_CHILD:
                        addWhere.append(com.ruoyi.common.utils.StringUtils.format(
                                " OR {}.dept_id IN ( SELECT dept_id FROM sys_dept WHERE dept_id = {} or find_in_set( {} , ancestors ) )",
                                deptAlias, user.getDeptId(), user.getDeptId()));
                        break;
                    case DATA_SCOPE_SELF:
                        if (com.ruoyi.common.utils.StringUtils.isNotBlank(userAlias)) {
                            addWhere.append(com.ruoyi.common.utils.StringUtils.format(" OR {}.user_id = {} ", userAlias, user.getUserId()));
                        } else {
                            // 数据权限为仅本人且没有userAlias别名不查询任何数据
                            addWhere.append(" OR 1=0 ");
                        }
                        break;
                }
            });
        }
        //都没有设置数据权限,则无权查询数据
        if (dataScopeSet.size() == 0) {
            addWhere.append(StringUtils.format(" OR {}.dept_id = 0 ", deptAlias));
        }
        if (addWhere.length() >= 4) {
            return "(" + addWhere.substring(4) + ")";
        }
        return "";
    }

对照若依之前的dataScopeFilter，这里SQL重写做了四个改进

获取用户所有角色的数据权限，并去重（用Set存储）
数据权限中如果有全部权限，则直接不拼接SQL
遍历数据权限（若依是遍历角色）去拼接SQL，这样有多少个种数据权限就组装多少次 SQL，最多也就是4种权限（自定义、部门数据、部门及以下、个人数据）
对数据权限先做排重，减少后续SQL组装，核心改造前后对比

改造前

改造后

举个例子说明，如果一个用户有 110,111,112,113,114 四个角色，每个角色都有自定义部门数据，那么最终改写的SQL语句有可能是这样：

OR d.dept_id IN ( SELECT dept_id FROM sys_role_dept WHERE role_id in(110,111,112,113,114)) ,这里一次性将所有角色进行查询，这样就用一条SQL完成了之前的4条SQL的权限查询。如果每个角色都有不同数据权限（5种），除去全部权限外最多也是四种，那么最后只会生成4条SQL语句。比如：

角色 110 数据权限 2

角色 111 数据权限 2

角色 112 数据权限 3

角色113 数据权限 4

角色 114 数据权限 2

合并后，数据权限只有 2,3,4三种，角色有 110,111,112,113,114 五个，最终生成的SQL最多也是3个.

以上就是本次对若依框架中的数据权限这个模块进行的二次改造，整体上是从service拦击切换到了Mapper层更接近数据层，其次就是去除了对BaseEntity查询对象中的params参数依赖，最后就是对SQL改写核心实现方式从结构上做了一个优化，降低SQL重复率。

相关推荐

取消回复欢迎你发表评论:

使用cheat engine修改unity游戏（cheat engine教程）

1分钟了解Tableau

钉钉打卡虚拟定位赶快点赞收藏吧!

超级硬核的钉钉模拟wifi，定位，远程打卡教程

足不出户便能环游世界!手机发微信朋友圈如何定位到国外?

6米跨度柱子一般多大?框架结构的柱子应该设置多大?

项目使用 Jfrog Artifactory 制品库

.NET 多版本 WinForm 开源控件库 SunnyUI 技术解析与示例代码

美国陆军游骑兵和长程侦察巡逻部队军服图册

SpringBoot的starter到底是什么?