用户,角色,资源,联合查询(使用xml)

向xml低头,没错,我向xml低头了。
前文:
用户,角色,资源,联合查询(使用注解SQL)

注解sql的那种provider的文件格式,可能真的不是mybatis主推的模式,场景欠缺的很多,而当你硬把改场景用这种方式实现时,反倒不优雅了。还是回归传统吧,或许这就是xml这么多年屹立不倒的秘诀。

开始开始。

一段时间不见,gemini的表结构被我改了改,结合各种方面优化考虑,现在的他们是这样的。
用户表:

CREATE TABLE `g_user` (
  `id` int(32) NOT NULL AUTO_INCREMENT COMMENT '主键id',
  `user_id` bigint(32) NOT NULL COMMENT '用户编号(业务id)',
  `identity_code` varchar(64) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL COMMENT '账号',
  `nick_name` varchar(64) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL COMMENT '昵称',
  `phone` varchar(32) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL COMMENT '联系方式',
  `email` varchar(64) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL COMMENT '邮箱',
  `password` varchar(32) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL COMMENT '密码',
  `lock` tinyint(1) DEFAULT '0' COMMENT '是否锁定',
  `create_user_id` bigint(32) DEFAULT NULL COMMENT '创建人id',
  `update_user_id` bigint(32) DEFAULT NULL COMMENT '更新人id',
  `create_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `rev` tinyint(8) DEFAULT '1' COMMENT '版本号',
  `delete_flag` tinyint(1) DEFAULT '0' COMMENT '删除标记',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

角色表:

CREATE TABLE `g_role` (
  `id` int(32) NOT NULL AUTO_INCREMENT COMMENT '主键id',
  `role_id` bigint(32) NOT NULL COMMENT '角色id',
  `role_code` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '角色编码',
  `role_name` varchar(64) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL COMMENT '角色名称',
  `create_user_id` bigint(32) DEFAULT NULL COMMENT '创建人id',
  `update_user_id` bigint(32) DEFAULT NULL COMMENT '更新人id',
  `create_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `rev` tinyint(8) DEFAULT '1' COMMENT '版本号',
  `delete_flag` tinyint(1) DEFAULT '0' COMMENT '删除标记',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

用户角色表:

CREATE TABLE `g_user_role` (
  `id` int(32) NOT NULL AUTO_INCREMENT COMMENT '主键id',
  `role_id` bigint(32) NOT NULL COMMENT '角色编码',
  `user_id` bigint(32) NOT NULL COMMENT '用户编码',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

资源表:

CREATE TABLE `g_resource` (
  `id` int(32) NOT NULL AUTO_INCREMENT COMMENT '主键id',
  `resource_id` bigint(32) NOT NULL COMMENT '资源id',
  `resource_code` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '资源编码',
  `resource_name` varchar(64) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL COMMENT '资源名称',
  `create_user_id` int(32) DEFAULT NULL COMMENT '创建人id',
  `update_user_id` int(32) DEFAULT NULL COMMENT '更新人id',
  `create_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `rev` tinyint(8) DEFAULT '1' COMMENT '版本号',
  `delete_flag` tinyint(1) DEFAULT '0' COMMENT '删除标记',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

角色资源表:

CREATE TABLE `g_res_role` (
  `id` int(32) NOT NULL AUTO_INCREMENT COMMENT '主键id',
  `role_id` bigint(32) NOT NULL COMMENT '角色id',
  `resource_id` bigint(32) NOT NULL COMMENT '资源id',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

总体模式同过去没有区别,只是加了一些字段,改了一些名字,变化了一些规则。
首先,过去我的表主键都是自增id,但我在映射关系中,也是使用的自增id,其实是不科学的。过去也不是没想到给它一个主键自增id,一个业务id,一个编码,一个名字。所有的业务表都这么设计的模式。只是觉得有必要吗?但是实际的项目探索之后,其实还是很有必要的。粒度越细,其实可变化性就越多,分工也越明确。只是略有复杂需要处理,具体还是看个人和项目吧。总之我改成了现在的这样。

开始切入正题。

我们现在需求的返回格式同过去一般无二。
1、用户信息中带角色列表,角色列表中再带资源列表。
2、用户信息中直接带角色列表与资源列表。

对于vo文件我也没有怎么改动。除了字段更名和添加字段以外,格式,模式,基本同过去一致。

主要看xml。
其实本质是类似的。还是使用resultMap进行调控。
只是在注解sql中,用的是many=@Many()这样的格式,在这里使用的就是collection标签。需要注意的是,所有的关联字段(column)都必须显式地被写出来,也就是不能依赖通配符(*)的查询结果。

直接贴图吧。

资源持久化类
ResourceMapper.java:

public interface ResourceMapper {

    /**
     * 根据roleId获取资源信息
     */

    List<ResourceVo> selectByRoleId(Long roleId);
}

ResourceMapper.xml
很简单,只是普通的根据角色资源映射表查询资源信息。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.hekiraku.gemini.mapper.ResourceMapper">
    <resultMap id="resourceInfo" type="com.hekiraku.gemini.domain.vo.ResourceVo">
    </resultMap>
    <select id="selectByRoleId" resultMap="resourceInfo">
        select gr.*
        from g_resource gr
        left join g_res_role grr on gr.resource_id = grr.resource_id
        where grr.role_id = #{roleId}
    </select>
</mapper>

接下来看角色
角色持久化类
RoleMapper.java

public interface RoleMapper {
/**根据userId获取所有角色信息*/
    List<RoleVo> selectByUserId(Long userId);
}

RoleMapper.xml
<注意:这里的关联字段是role_id,因此在下面的sql中就显式地把它查了出来。>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.hekiraku.gemini.mapper.RoleMapper">
    <resultMap id="roleInfo" type="com.hekiraku.gemini.domain.vo.RoleVo">
        <collection property="resources" column="role_id" javaType="java.util.List" select="com.hekiraku.gemini.mapper.ResourceMapper.selectByRoleId"/>
    </resultMap>
    <!--根据userId获取相关角色信息-->
    <select id="selectByUserId" resultMap="roleInfo">
        select gr.*,grr.role_id as roleId
        from g_role gr
        left join g_user_role grr on gr.role_id = grr.role_id
        where grr.user_id = #{userId}
    </select>
</mapper>

用户映射类
userMapper.java:

public interface UserMapper {
/**根据身份编码获取所有信息*/
    UserInfoVo selectByIdentityCode(String identityCode);
}

userMapper.xml:
<注意:这里的关联字段是user_id,因此在下面的sql中就显式地把它查了出来。>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.hekiraku.gemini.mapper.UserMapper">

    <resultMap id="userInfo" type="com.hekiraku.gemini.domain.vo.UserInfoVo">
        <collection property="roles" column="user_id" ofType="com.hekiraku.gemini.domain.vo.RoleVo" javaType="java.util.List" select="com.hekiraku.gemini.mapper.RoleMapper.selectByUserId"/>
    </resultMap>
    <select id="selectByIdentityCode" resultMap="userInfo">
        select gu.user_id as userId,gu.*
        from g_user gu
        where gu.identity_code = #{identityCode}
    </select>
</mapper>

关联字段是什么呢?就是两个sql关联在一起的那个共同的字段。所以在写关联查询的时候,一定一定要注意的事,关联字段一定要作为B的条件。

结果集

end

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 196,165评论 5 462
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 82,503评论 2 373
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 143,295评论 0 325
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,589评论 1 267
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,439评论 5 358
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,342评论 1 273
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,749评论 3 387
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,397评论 0 255
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,700评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,740评论 2 313
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,523评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,364评论 3 314
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,755评论 3 300
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,024评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,297评论 1 251
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,721评论 2 342
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,918评论 2 336

推荐阅读更多精彩内容