Mybatis | Discriminator | 鉴别器

前言

[转] ---- 来自 （luckyharry4）
最近干了一个工作是使用discriminator去写一个新的API，那么写这个新的API原因是什么呢？原因是这样的：我们的项目使用Mybatis，我们项目中有一个实体类叫做User，在User中还含有很多别的实体类，例如Role，Permission，Address等（有经验的肯定知道这种嵌套实体类的情况，使用和）。然后之前有一个API是把User以及关联的所有实体类都给查出来。从现在看起来，并没有什么不合理的地方。
但是随着项目不断扩大很多地方需要查询User一个这有一个现成的API就直接使用了，哪怕需求只是获取一个简单的用户名称。这种大材小用的地方多了，不但导致了调用的地方回来的很慢，还导致了服务器性能的浪费。
很多人肯定会说就是因为懒，如果多写几个sql，每个sql按照需要返回不就好了吗？确实可以这样去做，但是这导致了，我们得不停的写重复的sql，然后写resultMap，最后返回。这种重复的工作，对于一个程序员是不可以容忍的。
所以，引出了今天的主人公——discriminator。
---- 来自 （luckyharry4）

这位作者将问题背景介绍得很清楚。下面所引用的代码例子也是出自该篇文章。
方便以后查阅。

Discriminator（鉴别器）

用了 Mybatis 框架工作这么久，却没有发现鉴别器的存在，实在惭愧。现在需要对他有一个认识，学习有关于它的用法。

疑问列出

在框架中，这个鉴别器，主要作用是什么呢？（经验告诉我，通过百度没有直接看懂的话，就先让自己开开脑洞，让自己先想象一下）

把上面的疑问，细化了以下几个疑问。
鉴别了什么，鉴别出结果了后会怎么样？鉴别的根据是什么？

基本介绍

鉴别器，是通过注解或者xml标签形式，在给定sql查询列中某个字段的值中匹配到相应的ResultMap。

这个字段的值通过mapper接口的方法参数传递而来，所以在我们的程序场景中，便可根据实际情况选择对应的ResultMap。

ResultMap的作用，是做字段和属性的自动匹配，或者复杂类型数据的匹配，或者通过其 select 属性再完成一次数据库查询。

在Mybatis官网中也有鉴别器相关的介绍。

有时候，一个数据库查询可能会返回多个不同的结果集（但总体上还是有一定的联系的）。 鉴别器（discriminator）元素就是被设计来应对这种情况的，另外也能处理其它情况，例如类的继承层次结构。 鉴别器的概念很好理解——它很像 Java 语言中的 switch 语句。

image.png

从官网的介绍中，一下子让我想到了自己处理复杂查询的处理方式，不正是为了达成该设计所要达到的最终目的吗。下面的小节中简单说一下。

T 只转化为一种DTO并不够用

一个查询结果 T ，在业务场景不同的情况下，最终组成的数据可能不同。

1. T 数据已经够用
2. 在APP端查询中，可能T的数据不够用，仍需要获取其它app相关的数据， 需要 T 转化为 AppDTO
3. 在PC端中， 可能需要转化为 PcDTO。

转化为DTO的方法，我一般都是写在程序中，该方法的处理是将T转化为DTO时候，仍缺失的数据，都在此方法中再次查询数据库获得，最终组装成前端所需要的DTO数据。

这个DTO的转化方法，在我看来，它有以下好处：
1.在新公司中接触到DTO转化方法这种方式，个人觉得档次高些些（想法有些俗气）。
2.是简化了XML，减少我们写复杂SQL，联表SQL的机会，ResultMap相对也是比较少。

这些XML里面的东西，只要编写注重格式规范，注释到位，其实也不是不可以接受。

toDTO的方式，如果只是简单的数据组装，那mybatis框架当然可以胜任，定义一个ResultMap`可以解决。再想想，多种结果意味着需要编写多个ResultMap，多次SQL相似的语句，那XML文件中的代码看起来得多了不少。能不能减少一些SQL的填写，有没有更好组织ResultMap的灵活方式呢?

这就要涉及到在Mybatis框架中的发现了。

鉴别器相关代码

粗讲一下沾边的话，看过留一个印象，理一下思路。

1.鉴别的东西是（case）， case对应ResultMap 。
2.匹配（鉴别）case的过程是一个匹配ResultMap的过程。
3.case是我们列出的所有情况。就像 switch(x) ... case一样，匹配的根据是运行时提供的，它是动态的，一般是所有case的其中之一。

相关的类

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface TypeDiscriminator {
  String column();
  Class javaType() default void.class;
  JdbcType jdbcType() default JdbcType.UNDEFINED;
  Class typeHandler() default UnknownTypeHandler.class;
  Case[] cases();
}

column：用来指定select 列字段，可以是表中的字段，也可以是自定义字段，字段值在鉴别器看来，好比是 switch(x) 中的 x。

Case[]: 每一种Case对应一种ResultMap。可以通过条件值（column的值）去选择不同的ResultMap.

在 MapperAnnotationBuilder类中，我们可以看到鉴别器的相关代码，这里是框架注册鉴别器中的所有case。

MapperAnnotationBuilder类中的相关代码

鉴别器的用法

如果ResultMap中没有使用鉴别器，对于嵌套类中的值映射写法如下：

通过标签discriminator使用鉴别器，基本写法是这样的：

每个 case 标签对应的ResultMap如下：

在标记的 column 中传值

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

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