这期内容当中小编将会给大家带来有关Java中怎么利用Mybatis实现数据权限控制，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
创新互联公司是一家专注网站建设、网络营销策划、微信小程序开发、电子商务建设、网络推广、移动互联开发、研究、服务为一体的技术型公司。公司成立10年以来，已经为上千余家凿毛机各业的企业公司提供互联网服务。现在，服务的上千余家客户与我们一路同行，见证我们的成长；未来，我们一起分享成功的喜悦。
URL访问资源（接口以及网页） 界面元素资源（增删改查导入导出的按钮，重要的业务数据展示与否等） 数据资源
现在业内普遍的实现方案实际上很粗放，就是单纯的“菜单控制”，通过菜单显示与否来达到控制权限的目的。
我仔细分析过，现在大家做的平台分为To C和To B两种：
To C一般不会有太多的复杂权限控制，甚至大部分连菜单控制都不用，全部都可以访问。 To B一般都不是开放的，只要做好认证关口，能够进入系统的只有内部员工。大部分企业内部的员工互联网知识有限，而且作为内部员工不敢对系统进行破坏性的尝试。
所以针对现在的情况，考虑成本与产出，大部分设计者也不愿意在权限上进行太多的研发力量。
菜单和界面元素一般都是由前端编码配合存储数据实现，URL访问资源的控制也有一些框架比如SpringSecurity，Shiro。
目前我还没有找到过数据权限控制的框架或者方法，所以自己整理了一份。
数据权限控制原理
数据权限控制最终的效果是会要求在同一个数据请求方法中，根据不同的权限返回不同的数据集，而且无需并且不能由研发编码控制。这样大家的第一想法应该就是AOP，拦截所有的底层方法，加入过滤条件。这样的方式兼容性较强，但是复杂程度也会更高。我们这套系统中，采用的是利用Mybatis的plugin机制，在底层SQL解析时替换增加过滤条件。这样一套控制机制存在很明显的优缺点，首先缺点：
适用性有限，基于底层的Mybatis。 方言有限，针对了某种数据库（我们使用MySQL），而且由于需要在底层解析处理条件所以有可能造成不同的数据库不能兼容。当然redis和NOSQL也无法限制。
当然，假如你现在就用Mybatis，而且数据库使用的是Mysql，这方面就没有太大影响了。
接下来说说优点：
减少了接口数量及接口复杂度。原本针对不同的角色，可能会区分不同的接口或者在接口实现时利用流程控制逻辑来区分不同的条件。有了数据权限控制，代码中只用写基本逻辑，权限过滤由底层机制自动处理。 提高了数据权限控制的灵活性。例如原本只有主管能查本部门下组织架构/订单数据，现在新增助理角色，能够查询本部门下组织架构，不能查询订单。这样的话普通的写法就需要调整逻辑控制，使用数据权限控制的话，直接修改配置就好。
数据权限实现
上一节就提及了实现原理，是基于Mybatis的plugins）实现。
MyBatis 允许你在已映射语句执行过程中的某一点进行拦截调用。默认情况下，MyBatis 允许使用插件来拦截的方法调用包括：Executor (update, query, flushStatements, commit, rollback, getTransaction, close, isClosed)ParameterHandler (getParameterObject, setParameters)ResultSetHandler (handleResultSets, handleOutputParameters)StatementHandler (prepare, parameterize, batch, update, query)
Mybatis的插件机制目前比较出名的实现应该就是PageHelper项目了，在做这个实现的时候也参考了PageHelper项目的实现方式。所以权限控制插件的类命名为PermissionHelper。
机制是依托于Mybatis的plugins机制，实际SQL处理的时候基于jsqlparser这个包。
设计中包含两个类，一个是保存角色与权限的实体类命名为PermissionRule，一个是根据实体变更底层SQL语句的主体方法类PermissionHelper。
首先来看下PermissionRule的结构：
public class PermissionRule {private static final Log log = LogFactory.getLog(PermissionRule.class);/*** codeName
* 适用角色列表
* 格式如: ,RoleA,RoleB,*/private String roles;/*** codeValue
* 主实体，多表联合* 格式如: ,SystemCode,User,*/private String fromEntity;/*** codeDesc
* 过滤表达式字段,
* {uid}会自动替换为当前用户的userId
* {me} main entity 主实体名称* {me.a} main entity alias 主实体别名* 格式如：*
看完这个结构，基本能够理解设计的思路了。数据结构中保存如下几个字段：
角色列表：需要使用此规则的角色，可以多个，使用英文逗号隔开。 实体列表：对应的规则应用的实体（这里指的是表结构中的表名，可能你的实体是驼峰而数据库是蛇形，所以这里要放蛇形那个），可以多个，使用英文逗号隔开。 表达式：表达式就是数据权限控制的核心了。简单的说这里的表达式就是一段SQL语句，其中设置了一些可替换值，底层会用对应运行时的变量替换对应内容，从而达到增加条件的效果。 规则说明：单纯的一个说明字段。
核心流程
系统启动时，首先从数据库加载出所有的规则。底层利用插件机制来拦截所有的查询语句，进入查询拦截方法后，首先根据当前用户的权限列表筛选出PermissionRule列表，然后循环列表中的规则，对语句中符合实体列表的表进行条件增加，最终生成处理后的SQL语句，退出拦截器，Mybatis执行处理后SQL并返回结果。
讲完PermissionRule，再来看看PermissionHelper，首先是头：
@Intercepts({@Signature(type = Executor.class, method = "update", args = {MappedStatement.class, Object.class}),@Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class})})public class PermissionHelper implements Interceptor {}
头部只是标准的Mybatis拦截器写法，注解中的Signature决定了你的代码对哪些方法拦截，update实际上针对修改（Update）、删除（Delete）生效，query是对查询（Select）生效。
下面给出针对Select注入查询条件限制的完整代码：
private String processSelectSql(String sql, List
重点思路
重点其实就在于Sql的解析和条件注入，使用开源项目JSqlParser。
解析出MainTable和JoinTable。from之后跟着的称为MainTable，join之后跟着的称为JoinTable。这两个就是我们PermissionRule需要匹配的表名，PermissionRule::fromEntity字段。 解析出MainTable的where和JoinTable的on后面的条件。使用and连接原本的条件和待注入的条件，PermissionRule::exps字段。 使用当前登录的用户信息（放在缓存中），替换条件表达式中的值。 某些情况需要忽略权限，可以考虑使用ThreadLocal（单机）/Redis（集群）来控制。
上述就是小编为大家分享的Java中怎么利用Mybatis实现数据权限控制了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。
