Mybatis之discriminator（鉴别器）详解

前言

最近干了一个工作是使用discriminator去写一个新的API，那么写这个新的API原因是什么呢？原因是这样的：我们的项目使用Mybatis，我们项目中有一个实体类叫做User，在User中还含有很多别的实体类，例如Role，Permission，Address等（有经验的肯定知道这种嵌套实体类的情况，使用和）。然后之前有一个API是把User以及关联的所有实体类都给查出来。从现在看起来，并没有什么不合理的地方。

但是随着项目不断扩大很多地方需要查询User一个这有一个现成的API就直接使用了，哪怕需求只是获取一个简单的用户名称。这种大材小用的地方多了，不但导致了调用的地方回来的很慢，还导致了服务器性能的浪费。

很多人可定会说就是因为懒，如果多谢几个sql，每个sql按照需要返回不就好了吗？确实可以这样去做，但是这导致了，我们得不停的写重复的sql，然后写resultMap，最后返回。这种重复的工作，对于一个程序员是不可以容忍的。

所以，引出了今天的主人公——discriminator。

正文

我们应该如何使用鉴别器呢？别着急咱们慢慢看。

如果没有使用鉴别器，返回实体类以及嵌套的实体类的resultMap应该是这样的：

鉴别器使用后的基本写法是这样的：

1. column字段是指定我们要根据哪一个数据库查询字段进行判断，这个值可以是真实在数据库中存在的属性，也可以不存在，如果不存在的话，我们可以给实体类添加一个这个标识位属性，或者使用继承，继承父类，然后多加一个标志位属性，放在子类上。细心的读者，肯定看出来，改造前的resultMap的type为RoleModel，改造后的type为ElasticRoleModel。
2. javaType指定的是column那个字段在实体类中是什么类型的。
3. value属性就是我们刚刚指定的那个属性值不同的情况，具体返回哪一个resultMap。也就是说如果role_profile_flag属性值为1的情况下，会返回ElasticRoleUserMap 的resultMap
4. 如果你指定的那个值与所有case中的值都不相同，则会把最外层的resultMap，也就是ElasticRoleMap进行返回，其中就会返回这个resultMap最基本的那些属性（鉴别器之外的值）。

下面给出每个case返回的resultMap的样例：

1. 我们之所以继承了使用鉴别器的那个resultMap是因为我们希望每个case返回的resultMap会包含所有鉴别器之外公共的变量
2. resultMap中的collection就是嵌套的那些实体类的具体赋值实现，这里不做过多解释
3. 上面知识给出了三个例子，不光只有这三种，还可以俩俩的组合，或者是三个的组合形式

最后给出来，我们这个弹性查询的基础sql，他只是负责了最基本的查询，这个sql所查询出来的数据，无论在鉴别器case中，或者不在鉴别器case中，都会进行返回，因为他们不是嵌套的那些实体类。

    
        SELECT
            ro.*,
            out_tran.transaction_id as validated_transaction_id,
            #{roleFlag, jdbcType=INTEGER} as role_profile_flag
        FROM
            platform.role ro
            
        WHERE ro.role_id = #{roleId,jdbcType=BIGINT}
    

1. 这里的roleFlag就是实体类中标志位，因为我们的这个标志位不是真实在数据库中存在的，所有传入后，直接通过这种形式进行返回。as后的名称一定要与鉴别器中的column字段一致。
2. resultMap就是刚刚我们定义好的含有鉴别器的那个基础的resultMap

后记

今天就先总结到这里，我也是当时做的时候遇到了不少的坑，如果有什么其他的问题，可以在下方评论给我，咱们可以互相成长。谢谢大家。