Java EE开发平台随手记5——Mybatis动态代理接口方式的原生用法

　　为了说明后续的Mybatis扩展，插播一篇广告，先来简要说明一下Mybatis的一种原生用法，不过先声明：下面说的只是Mybatis的其中一种用法，如需要更深入了解Mybatis，请参考官方文档，或者研读源码。　　

　　我们知道，使用Mybatis的方式有很多种，从是否集成上分，可以单独使用，也可以和Spring集成使用；从使用方式上分，可以编写静态工具类，在静态工具中调用SqlSession，也可以直接注入SqlSession/ SqlSessionTemplate，还可以编写Dao接口，让mybatis自动生成代理子类（对于只编写接口，不写实现类就可以运行有疑问的朋友，可以先了解一下JDK中的动态代理技术，这里就不展开了）；在sql脚本的编写上，可以使用xml——也就是通常所说的SqlMapper，可以使用注解，还可以使用Mybatis提供的API生成等等。

　　根据新平台运行环境和之前同事的开发习惯，我们的选择组合是（姑且称之为动态代理接口方式或代理接口）：集成Spring + Dao接口/自动动态代理子类 + SqlMapper配置。

　　代理接口方式，我们姑且不管是怎么样代理的，但能够运行起来，肯定是有一段真正的可以运行的代码——实际上就是调用SqlSession接口中的方法。因此首先需要解决的就是下面三个基本问题：

问题1：确定需要执行的sqlId

　　从SqlSession接口的方法签名可以知道，所有的数据访问方法，都必须有一个参数“statement”，也就是我们通常所说的sqlId。那么，sqlId是怎么确定的？SqlMapper中那么多配置，Mybatis怎么知道调用哪一个？

问题2：确定需要执行的方法

　　不管是用哪种方式，归根结底还是调用SqlSession接口中的方法，那么问题来了，SqlSession接口中那么多不同方法，怎么知道调用哪一个呢？比如Dao接口中的一个查询方法，是调用SqlSession的selectOne？还是selectList？还是有回调的select？还是分页查询呢？

问题3：确定执行SQL时的参数

　　除了sqlId，还有执行SQL时的参数，也是需要解决的一个基本问题，如果Dao接口中有多个参数，传入了多个参数，又怎么组装成一个统一的参数呢？SQL运行时的参数也会影响到执行的方法，因为很多重载的方法就只能通过运行时参数来确定。

　　下面，我们带着这三个问题，看一个简单的用户维护的例子，分析一下代理接口方式原生用法是怎么处理这三个问题的，然后，也思考一下Mybatis的处理有没有什么不足和缺陷，我们又怎么处理这些不足和缺陷？

　　业务场景做了简化，用户模型只包括用户ID、用户名称和用户所属的机构，需要完成的操作有：查询用户列表、查询用户列表（分页查询）、查找用户对象、新增用户、修改用户以及删除用户。

（1）Dao接口

 @Repository("userDao")
 public interface IUserDao {
 
     /**
      * 查询用户列表
      * @param user    用户查询参数
      * @return
      */
     public List<UserBean> dList(UserForm user);
 
     /**
      * 查询用户列表（分页查询）
      * @param user    用户查询参数
      * @param page  分页对象
      * @return
      */
     public List<UserBean> dPageList(UserForm user, IPage page);
 
     /**
      * 查找单个用户
      * @param userId 用户ID
      * @return
      */
     public UserBean dFind(@Param("userId")String userId);
 
     /**
      * 新增单个用户
      * @param user
      * @return
      */
     public int dInsert(UserForm user);
 
     /**
      * 更新单个用户
      * @param user
      * @return
      */
     public int dUpdate(UserForm user);
 
     /**
      * 删除单个用户
      * @param userId
      * @return
      */
     public int dDelete(@Param("userId")String userId);
 }

（2）SqlMapper配置

 <?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.forms.beneform4j.webapp.systemmanage.user.dao.IUserDao">
 
     <select id="dList" resultType="com.forms.beneform4j.webapp.systemmanage.user.bean.UserBean">
         SELECT U.USER_ID, U.USER_NAME, U.ORG_ID
           FROM BF_USER U
          <where>
              <if test="null != userId and '' != userId">
                  AND U.USER_ID = #{userId, jdbcType=VARCHAR}
              </if>
              <if test="null != orgId and '' != orgId">
                  AND U.ORG_ID = #{orgId, jdbcType=VARCHAR}
              </if>
              <if test="null != userName and '' != userName">
                  AND U.USER_NAME LIKE '%'||#{userName, jdbcType=VARCHAR}||'%'
              </if>
          </where>
          ORDER BY U.ORG_ID, U.USER_ID
     </select>
 
     <select id="dPageList" resultType="com.forms.beneform4j.webapp.systemmanage.user.bean.UserBean">
         SELECT U.USER_ID, U.USER_NAME, U.ORG_ID
           FROM BF_USER U
          <where>
              <if test="null != userId and '' != userId">
                  AND U.USER_ID = #{userId, jdbcType=VARCHAR}
              </if>
              <if test="null != orgId and '' != orgId">
                  AND U.ORG_ID = #{orgId, jdbcType=VARCHAR}
              </if>
              <if test="null != userName and '' != userName">
                  AND U.USER_NAME LIKE '%'||#{userName, jdbcType=VARCHAR}||'%'
              </if>
          </where>
          ORDER BY U.ORG_ID, U.USER_ID
     </select>
 
     <select id="dFind" resultType="com.forms.beneform4j.webapp.systemmanage.user.bean.UserBean">
         SELECT U.USER_ID, U.USER_NAME, U.ORG_ID
           FROM BF_USER U
          WHERE U.USER_ID = #{userId, jdbcType=VARCHAR}
     </select>
 
     <insert id="dInsert" >
         INSERT INTO BF_USER (USER_ID, USER_NAME, ORG_ID)
         VALUES (#{userId,jdbcType=VARCHAR}, #{userName,jdbcType=VARCHAR}, #{orgId,jdbcType=VARCHAR})
     </insert>
     <update id="dUpdate" >
         UPDATE BF_USER
            SET USER_NAME = #{userName,jdbcType=VARCHAR},
                ORG_ID = #{orgId,jdbcType=VARCHAR}
          WHERE USER_ID = #{userId,jdbcType=VARCHAR}
     </update>
     <delete id="dDelete">
         DELETE FROM BF_USER
          WHERE USER_ID = #{userId, jdbcType=VARCHAR}
     </delete>
 </mapper>

　　现在来看Mybatis是怎么解决上面的问题的。

　　第一个问题：确定需要执行的sqlId

　　Mybatis的解决方法很简单，就是将接口类加上方法作为sqlId，可以用下面一个公式来描述：

需要执行的SqlId
 = Dao接口所在的类名（全限定名）+ 点号（.）+ 方法名
 = SqlMapper配置文件中的命名空间 + 点号(.) + [select|insert|update|delete]元素的id属性

　　有什么不足呢？很明显，以下几种情形都无法处理：

1. 两个重载的方法(方法名相同，参数不同)，需要执行不同的sqlId
2. 两个不同名的方法，需要引用相同的sqlId配置(参数不同，比如查询列表和查找元素，就常常可以共用一个<select>配置)
3. 当前Dao中的方法需要引用命名空间和全限定类名不一致的sqlId（比如有一个公共<select>配置，各个业务模块都有可能引用这段配置，当然，这种情况下并不建议dao直接引用<select>配置，而建议编写一个公共服务）
4. 此外，对于我们前面博客中提到的批量执行，也是无法处理的

　　其实，这里比较好一点的方法是添加一个类似下面的sqlId查找策略接口：

 public interface ISqlIdLookupStrategy {
 
     public String lookup(Method method);
 }

　　Mybatis可以实现一个默认查找策略，然后用户也可以自己实现这个查找策略，比如就可以利用这个接口实现sqlId的置换——是的，就是传说中的张大教主的乾坤大挪移。但是遗憾的是，Mybatis开发人员估计认为没有必要不按默认方法查找，所以直接在代码中写死了。更加遗憾的是，在我们自己的平台中，也因为种种评审，将这个接口给砍掉，理由是既然Mybatis没有提供，我们也就可以不提供（好有道理，我竟然无法反驳，所以做开发平台也有很多不爽的地方——这是后话，暂且不说了）。

　　第二个问题：确定需要执行的方法

　　确定了sqlId，Mybatis怎么确定需要执行的方法呢？

　　首先想到的，可以根据sqlId读取到SqlMapper中的配置（不用担心每次都去解析xml，Mybatis会有缓存的），然后就可以知道是select|insert|update|delete中的哪一种，因此，可以先确定sql语句的类型。对于insert、update、delete，基本上也就确定了调用方法，但是对于select，因为SqlSession中的方法还是很多，还需要进一步区分。

　　进而想到的是，可以根据dao接口方法的签名来区分，签名包括返回值和形参，比如返回值是void，并且形参中包含处理查询结果的回调接口ResultHandler，那么，就可以大致确定需要调用void select(String statement, ResultHandler handler)这族重载方法中的一种，进一步可以分析形参中是否包含分页参数RowBounds、是否包含执行参数从而选择重载方法中的其中一种；又比如可以根据返回值是否为集合（Collection）类型来区分是查询单笔（selectOne）还是查询列表（selectList）。

　　如果上面两种方法还确定不了，Mybatis还有第三种方式：在dao接口方法上添加特定的注解，比如使用@Flush表示批量执行，使用@MapKey表示selectMap等。

　　说了这么多，可能还不够清晰，那既然是程序员，那就用程序员的语言来沟通，把Mybatis的源码贴在这里：

 public Object execute(SqlSession sqlSession, Object[] args) {
     Object result;
     if (SqlCommandType.INSERT == command.getType()) {
       Object param = method.convertArgsToSqlCommandParam(args);
       result = rowCountResult(sqlSession.insert(command.getName(), param));
     } else if (SqlCommandType.UPDATE == command.getType()) {
       Object param = method.convertArgsToSqlCommandParam(args);
       result = rowCountResult(sqlSession.update(command.getName(), param));
     } else if (SqlCommandType.DELETE == command.getType()) {
       Object param = method.convertArgsToSqlCommandParam(args);
       result = rowCountResult(sqlSession.delete(command.getName(), param));
     } else if (SqlCommandType.SELECT == command.getType()) {
       if (method.returnsVoid() && method.hasResultHandler()) {
         executeWithResultHandler(sqlSession, args);
         result = null;
       } else if (method.returnsMany()) {
         result = executeForMany(sqlSession, args);
       } else if (method.returnsMap()) {
         result = executeForMap(sqlSession, args);
       } else {
         Object param = method.convertArgsToSqlCommandParam(args);
         result = sqlSession.selectOne(command.getName(), param);
       }
     } else if (SqlCommandType.FLUSH == command.getType()) {
         result = sqlSession.flushStatements();
     } else {
       throw new BindingException("Unknown execution method for: " + command.getName());
     }
     if (result == null && method.getReturnType().isPrimitive() && !method.returnsVoid()) {
       throw new BindingException("Mapper method '" + command.getName()
           + " attempted to return null from a method with a primitive return type (" + method.getReturnType() + ").");
     }
     return result;
   }

需要注意的是，上面的那些方法和步骤也并没有完全确定调用的方法，还需要根据调用时传入的实际参数类型进一步筛选。

　　简单总结一下，确定调用方法的依据：

1. SqlMapper中的元素名称，如select | insert | update | delete
2. 接口方法签名中特定类型或特定类型的子类型，如分页参数类型RowBounds、结果回调处理器类型ResultHandler
3. 接口方法的返回值，如是否集合Collection类型或数组类型
4. 接口方法的注解，如@Flush、@MapKey等
5. 调用接口时的运行时参数

说到运行时参数，也引出第三个问题的处理：

　　第三个问题：确定执行SQL时的参数

　　上面例子中有的使用@Param注解，有的只是表单对象，有的包含类型的参数类型（如IPage等），Mybatis是怎么包装这些参数的呢？

　  首先有个规则：特殊类型参数不参与组装运行SQL时的参数，那什么是特殊类型参数？实际上就是有特殊意义的参数类型，在Mybatis原生用法中，只有两个，那就是分页对象类型RowBounds和结果回调处理类型ResultHandler，后面我们还会扩展这个特殊类型，添加IPage等。

除了特殊类型的参数之外，Mybatis按照如下的逻辑包装运行SQL时的参数：

1. 如果实参为null或者除了特殊类型参数外没有形参，那就直接返回null
2. 如果没有标注了@Param注解的形参，并且形参的个数只有1个（特殊类型参数之外），那么返回实参中的这个对应的参数对象，不做任何包装
3. 其它情形，先创建一个Map结构，将含@Param注解的参数以该注解的值为键值，对应索引处的实际参数为值存入Map结构，其它没有@Param注解的参数，就使用"param"加上索引序号为键值，对应实际参数为值存入Map结构，最后再返回这个Map结构作为SqlSession接口方法的参数对象

　　同样，把相关源码贴一下：

 public Object convertArgsToSqlCommandParam(Object[] args) {
     /**
      *  1.params 是一个类属性，属于Map类型，其中存储的是参数位置索引和@Param注解中value值的映射关系，但会忽略特殊类型的参数
      *  2.hasNamedParameters也是一个类属性，boolean类型，表示参数是否有@Param注解（只要任意一个参数有该注解就算有）
      */
     final int paramCount = params.size();
     if (args == null || paramCount == 0) {
         return null;
     } else if (!hasNamedParameters && paramCount == 1) {
         return args[params.keySet().iterator().next().intValue()];
     } else {
         final Map<String, Object> param = new ParamMap<Object>();
         int i = 0;
         for (Map.Entry<Integer, String> entry : params.entrySet()) {
             param.put(entry.getValue(), args[entry.getKey().intValue()]);
             // issue #71, add param names as param1, param2...but ensure
             // backward compatibility
             final String genericParamName = "param" + String.valueOf(i + 1);
             if (!param.containsKey(genericParamName)) {
                 param.put(genericParamName, args[entry.getKey()]);
             }
             i++;
         }
         return param;
     }
 }

　　对于执行参数的组装还不明确的朋友，可以自己跟踪源码调试分析一下。

　　上面三个基本问题很重要，这是我们赖以使用和扩展的基础。广告插播先到这里，后面继续记录对Mybatis的扩展使用。