Java EE开发平台随手记6——Mybatis扩展4

　　这篇博客中来说一下对Mybatis动态代理接口方式的扩展，对于Mybatis动态代理接口不熟悉的朋友，可以参考前一篇博客，或者研读Mybatis源码。

　　扩展11：动态代理接口扩展

　　我们知道，真正在Mybatis动态代理接口方式背后起作用的是SqlSession接口，类似地，我们的动态代理接口扩展则是基于IDaoTemplate接口，同样的，也需要解决相同的三个基本问题：

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

　　原生用法是根据包名、接口名、方法名去查找，但我们推荐添加一个sqlId的查找策略接口：

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

很简单，就只有一个方法，那就是根据接口中的方法查找需要执行的sqlId。Mybatis原生用法相当于如下实现：

1 public class MybatisSqlIdLookupStrategy implements ISqlIdLookupStrategy{
2
3     @Override
4     public String lookup(Method method) {
5         return method.getDeclaringClass().getName()+"."+method.getName();
6     }
7 }

那么，怎么处理上一篇博客中所说的几个问题呢？我的做法是引入一个新的注解@SqlRef，这也是引入的第一个注解：

 1 @Target(ElementType.METHOD)
 2 @Retention(RetentionPolicy.RUNTIME)
 3 @Documented
 4 public @interface SqlRef {
 5     /**
 6      * 标识使用哪个SqlId
 7      * @return sqlId值
 8      */
 9     String value() default "";
10
11     /**
12      * 指定相对于哪个类的路径，指定时，classpath选项将不起作用
13      * @return 指定前面的value()是相对于哪个类而言
14      */
15     Class<?> cls() default Null.class;
16
17     /**
18      * 是否为相对于当前类的路径
19      * @return 是否相对于当前类路径，当前类是指标示该注解方法所在的类
20      */
21     boolean classpath() default true;
22
23     /**
24      * 表示未配置类
25      */
26     public class Null{};
27 }

这个注解只能加到方法上面，并且一直到运行时都可以获取到相关信息，其中包括三个属性方法：

  1. value：标识sqlId，如果为空，就按默认方法取
  2. cls：value表示的sqlId是相对于哪个类，其中SqlRef.Null表示没有配置值，如果不是SqlRef.Null，解析sqlId的时候就添加cls.getName()+"."
  3. classpath：和cls类似，也是指示value值的相对类，默认值为true，表示相对于@SqlRef注解所标示的那个方法所在类，如果配置为false，则忽略@SqlRef注解所标示的方法所在类，如果cls和classpath都配置，以cls为准。

相当于是如下实现ISqlIdLookupStrategy接口：

 1 public class SqlRefSqlIdLookupStrategy implements ISqlIdLookupStrategy{
 2
 3     @Override
 4     public String lookup(Method method) {
 5         SqlRef sqlRef = method.getAnnotation(SqlRef.class);
 6         if(null != sqlRef){
 7             String sqlId = sqlRef.value();
 8             if(null == sqlId || "".equals(sqlId.trim())){
 9                 sqlId = method.getName();
10             }
11
12             Class<?> cls = sqlRef.cls();
13             if(null != cls && !SqlRef.Null.class.equals(cls)){
14                 sqlId = cls.getName() + "." + sqlId;
15             }else if(sqlRef.classpath()){
16                 sqlId = method.getDeclaringClass().getName() + "." +sqlId;
17             }
18             return sqlId;
19         }else{
20             return method.getDeclaringClass().getName()+"."+method.getName();
21         }
22     }
23 }

更进一步，还可以根据配置一个原sqlId和真正需要执行sqlId的映射关系，从而实现sqlId的偷梁换柱：

 1 public class MappingSqlIdLookupStrategy implements ISqlIdLookupStrategy{
 2
 3     private ISqlIdLookupStrategy proxy;
 4
 5     private Map<String, String> mapping;
 6
 7     @Override
 8     public String lookup(Method method) {
 9         String sqlId = null;
10         ISqlIdLookupStrategy proxy = getProxy();
11         if(null == proxy){
12             sqlId = method.getDeclaringClass().getName()+"."+method.getName();
13         }else{
14             sqlId = proxy.lookup(method);
15         }
16
17         Map<String, String> mapping = getMapping();
18         if(null != sqlId && mapping.containsKey(sqlId)){
19             return mapping.get(sqlId);
20         }else{
21             return sqlId;
22         }
23     }
24
25     // 省略 getter、setter方法
26 }

这里的实现没有继承MybatisSqlIdLookupStrategy或SqlRefSqlIdLookupStrategy，而是使用内部代理的方式，算是聚合优于继承原则的体现吧。

　　有了@SqlRef注解，对于执行单个sqlId的方法，就可以随心所欲的指向需要执行的sqlId了，很轻松的就解决了方法重载（方法名相同，但参数不同，执行的sqlId也不同）、不同名方法需要执行相同sqlId（比如查询列表、分页查询、查找等等）、需要执行其它命名空间中sqlId的问题了。但是@SqlRef对于需要一次性执行多个sqlId的批量，还是无能为力，这个问题我们等下再从另一个角度来看怎么处理，先接着看第2个问题：

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

　　相比SqlSession，IDaoTemplate接口添加了分页查询（物理分页）、流式查询、调用存储过程、批量执行（还有merge、case等方法，因为评审的时候去掉了，这里也就不展开了），怎么确定动态代理接口时需要调用的方法呢？其实很简单，沿用Mybatis的思路，无非是根据SqlMapper元素标签、dao接口方法签名（特殊参数和返回值）、特殊注解、运行时参数等等。

　　根据IDaoTemplate接口，目前确定执行方法的具体规则有：

  1. 如果返回值为整型数组int[]，作为批量执行处理（注意，这里会覆盖掉Mybatis原本就返回int[]数组的情形，但原本就返回int[]极少用到，所以关系不大）
  2. 如果返回值为存储过程调用结果类型ICallResult，作为存储过程调用
  3. 如果返回值为流式查询结果类型IListStreamReader，作为流式查询调用
  4. 其它情形下，按Mybatis原生方法确定需要执行的方法，有一点不同的是，把IPage类型的参数和RowBounds类型的参数作为同一类处理，都视作分页查询

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

　　除了批量执行，IDaoTemplate接口中方法形参和SqlSession中形参大同小异，所以执行SQL时的参数组装也是大同小异，大同就不说了，可参考上一篇博客，小异主要体现在：

  1. 分页参数IPage，作为特殊类型的参数，和RowBounds类型等同处理
  2. 流式查询selectListStream方法中还可以传入一个整型的fetchSize，表示每次读取的记录条数，因为整型参数和一般执行参数无法区分开来，所有我引入了@FetchSize注解，这也是引入的第2个注解：
 1 @Target({ElementType.METHOD, ElementType.PARAMETER})
 2 @Retention(RetentionPolicy.RUNTIME)
 3 @Documented
 4 public @interface FetchSize {
 5
 6     /**
 7      * 每次获取的记录条数
 8      * <p>
 9      *     注意：每次获取的记录条数数值范围为 (0, 5000]
10      * </p>
11      * @return 每次读取记录数大小
12      */
13     int value() default -1;
14 }

　　这个注解可以添加到方法上，加到方法时需要指定value值，表示每次读取的记录条数，具有全局性，也就是说每次调用方法，这个值都一样；另外，这个注解还可以加在整型方法参数前，表示这个参数是每次读取的记录条数，具有局部性，每次调用方法，都使用新传入的参数值。

　　到此为止，除了批量执行，三个基本问题都已经解决，而对于批量执行，我们也已经确定了，只有方法签名中返回值是整型数组int[]，才算是批量执行。下面我们就从批量执行的角度，再次讨论三个基本问题的处理。

　　批量执行三个基本问题的处理

　　首先，引进一个概念：可转换为集合类型的参数，什么意思呢？其实很简单，就是说这个参数可以转换成集合类型，比如数组类型的参数、迭代器类型的、本身就是集合类型的等等。看下面的代码可能更清晰（具体怎么转换，就不赘述了）：

1 private boolean isCollectionType(Class<?> cls){
2    return cls.isArray()
3        || Iterator.class.isAssignableFrom(cls)
4        || Enumeration.class.isAssignableFrom(cls)
5        || Iterable.class.isAssignableFrom(cls); //因此包含Collection，从而也包含List、Set、Queue等常见集合类型
6 }

　　其次，我们把批量执行分一下类，分成如下三种：

　　1. 一个sqlId，不同参数，执行多次

　　2. 一组sqlId，相同参数，执行多次，这里又分为两种：

　　　　2.1 一组sqlId，对应一个可转换为集合类型的参数，并且sqlId的个数和集合大小相同，一一对应的关系，每次执行不同sqlId，真正的执行参数也不相同

　　　　2.2 一组sqlId，对应相同的参数，每次执行不同sqlId，真正的执行参数完全相同

　　3.混合批量类型：一组sqlId，有的sqlId本身不是批量类型，有的sqlId本身又是一个批量类型（这个子批量类型就可以限制为批量类型1：即一个sqlId，不同参数多次执行，读者可以想想为什么？），他们的参数也不尽相同

　　准备工作做好了，现在来分别看怎么处理三个基本问题的：

批量类型1：一个sqlId，不同参数，执行多次

问题1：确定sqlId

　　因为是一个sqlId，所以很简单，和其它方法一样，使用ISqlIdLookupStrategy查找策略直接查找就行，可以使用原生用法，可以使用@SqlRef注解，还可以配置替换的映射关系，甚至可以同时使用其中的两种组合。

问题2：确定执行方法

　　从IDaoTemplate接口来看，一个sqlId执行多次的只有一个方法，实际上也就自然而然的确定了执行的方法

问题3：确定执行参数

　　一个sqlId执行多次，本质上就要求有一个可转换为集合类型的参数，然后将这个参数转换为真正的集合类型，从而可以循环迭代这个集合类型，每次使用其中的一个参数。这里会有一个问题，如果有多个可转换为集合类型的参数怎么办？为了防止歧义，我引入了@BatchParam注解，这也是引入的第三个注解：

 1 @Target({ElementType.PARAMETER, ElementType.METHOD})
 2 @Retention(RetentionPolicy.RUNTIME)
 3 @Documented
 4 public @interface BatchParam {
 5
 6     /**
 7      * 是否为批量，只适用于批量类型3
 8      * @return 是否为批量
 9      */
10     boolean value() default true;
11
12     /**
13      * 批量参数中每一项存入map结构时的名称
14      * @return 数据项名称
15      */
16     String item() default "item";
17
18     /**
19      * 表示批量参数的属性
20      * @return 批量参数属性
21      */
22     String property() default "this";
23
24     /**
25      * 当前索引存入map结构时的名称
26      * @return 索引名称
27      */
28     String index() default "index";
29 }

需要说明的是，虽然@BatchParam既可以添加到方法上，也可以添加到方法参数前，但是对于批量类型1，@BatchParam注解只有添加到方法参数前才生效，并且value属性方法不生效。看完这个注解的定义，再来说明怎么组装批量类型1的执行参数：

1、将所有执行参数按照Mybatis原生用法的方式组装成一个参数对象，记为P1

2、找出可转换为集合类型的参数，并真正转换为集合类型的参数，记为C2

　　具体算法：找到标有@BatchParam参数的入参，如果property()属性等于this，就将这个入参作为集合类型的参数，否则的话，就解析这个入参的对应属性值作为集合类型的参数（属性可以是任意ognl表达式），如果入参或者从入参解析出的参数不是可转换为集合类型的参数，就抛出异常

3、循环迭代C2，每次循环，创建一个map对象PM，将C2中对应索引处的值以@BatchParam.item()为key存入PM，将循环索引以@BatchParam.index()为key存入PM，对于参数对象P1，则做如下处理：如果P1是一个Map结构，直接将Map结构合并到PM对象中，否则将整个P1参数以"param1"为key存入PM

　　如果对上述过程不清楚的，建议多阅读几篇，编写几个实际例子，实际测试运行一下。

　　好了，sqlId找到了，集合类型的参数也准备好了，直接调用IDaoTemplate中public int[] executeBatch(String sqlId, List<?> parameters)就可以了。

批量类型2：一组sqlId，相同参数，执行多次

问题1：确定sqlId

　　因为有一组sqlId，所以原来的查找策略都失效了，这里我引入了@SqlRefs注解，这也是引入的第四个注解：

 1 @Target(ElementType.METHOD)
 2 @Retention(RetentionPolicy.RUNTIME)
 3 @Documented
 4 public @interface SqlRefs {
 5
 6     /**
 7      * @return {@link SqlRef}组，表示要执行的一组sqlId
 8      */
 9     SqlRef[] value();
10 }

非常简单，@SqlRefs里面可以包含多个@SqlRef，而每一个@SqlRef可以根据查找查找策略找到一个需要执行的sqlId，因此第一个问题，需要执行的sqlId数组也就解决了。

问题2：确定执行方法

　　从IDaoTemplate接口来看，一次执行一组sqlId的只有两个重置方法，没有本质上区别，只是执行时参数不同，因此执行方法结合第三个问题后也就解决了。

问题3：确定执行参数

　　这里根据是否有含@BatchParam注解的方法形参分为两种情况：

  • 具有包含@BatchParam注解的方法形参：这种情况下作为批量执行2.1处理，按照批量执行1中逻辑一样，确定集合类型的参数，然后检查sqlId的个数和集合类型参数大小是否一致，不一致抛出异常，一致的话，就一一对应的去执行
  • 不具有包含@BatchParam注解的方法形参：这种情况下作为批量执行2.2处理，先按照Mybatis原生方法组装参数对象，然后循环sqlId，每次都传入相同的参数对象取执行

批量类型3：混合批量类型，一组sqlId，其中每一个sqlId可以是批量，也可以不是批量，而且参数可以不同

问题1：确定sqlId

　　同样，有一组sqlId需要确定，使用原生方法或@SqlRef注解都无法解决问题，那使用@SqlRefs是否可以呢？如果只是确定一组sqlId，就想批量执行2中那样是没有问题的，但问题是，我们不但需要确定一组sqlId，而且还需要确定和每一个sqlId对应的参数，需要知道其中每一个sqlId本身是不是批量，因此不能简单实用@SqlRefs，为此，我引入了@Execute和@Executes注解，这也是引入的第五和第六个注解：

 1 @Target({ElementType.METHOD})
 2 @Retention(RetentionPolicy.RUNTIME)
 3 @Documented
 4 public @interface Execute {
 5
 6     /**
 7      * SqlRef引用
 8      * @return SqlRef引用
 9      */
10     SqlRef sqlRef();
11
12     /**
13      * 批量参数
14      * @return 批量参数
15      */
16     BatchParam param();
17
18     /**
19      * 执行的条件
20      * @return
21      */
22     String condition() default "";
23 }
24
25 @Target({ElementType.METHOD})
26 @Retention(RetentionPolicy.RUNTIME)
27 @Documented
28 public @interface Executes {
29
30     Execute[] value();
31 }

这里@Execute标示一次执行所需的信息，一次执行可以是一个简单语句，也可以是一个批量类型1，@Execute不能单独使用，必须嵌套在@Executes中，而@Executes标示一组执行（需要说明的是，这里的一次执行概念@Execute并不是和物理上和数据库交互一次，而只是一个逻辑上的划分，实际上，整个批量类型3只会和数据库交互一次）。可以参考下面的例子熟悉一下@Execute和@Executes的使用：

 1 @Executes({
 2         //更新角色基本信息
 3         @Execute([email protected]("dUpdateRole"), [email protected](false)),
 4         //删除角色权限关系
 5         @Execute([email protected]("dDeleteRolePermissionByPermTypes"), [email protected](value=false)),
 6         //重新添加角色权限关系
 7         @Execute([email protected]("dInsertRolePermission"), [email protected](item="perm", property="permissions")),
 8         //如果页面加载过角色的分配角色信息，就先删除角色与分页角色关系，因为不是子批量类型，所以需要显示条件执行的条件
 9         @Execute([email protected]("dDeleteRoleRoleAllot"), [email protected](value=false), condition="roleAllotLoaded"),
10         //新增角色与分配角色关系，这里不需要添加condition配置，因为会有一个隐式条件，如果是一个sqlId多次执行的子批量，而集合类型的参数为空，则不实际执行
11         @Execute([email protected]("dInsertRoleRoleAllot"), [email protected](item="allot", property="roleAllots"))
12 })
13 public int[] dUpdate(RoleForm role);

这个例子的业务场景是：更新一个角色，其中角色包含角色基本信息，角色和权限的关系（1对多），角色与分配角色的关系（1对多），然后前端页面传入的参数是角色基本信息，角色权限信息，如果点击了角色与分配角色的关系，就再传入角色的分配角色信息，否则就没有角色的分配角色信息（这里没有不表示清除这个关系，而只是页面没有加载，不需要变化）。

　　可以看到，每一个@Execute都有一个@SqlRef，从而也就解决了执行的sqlId数组问题。

问题2：确定执行方法

　　同批量执行2，从IDaoTemplate接口来看，一次执行一组sqlId的只有两个重置方法，没有本质上区别，只是执行时参数不同，因此执行方法结合第三个问题后也就解决了。

问题3：确定执行参数

　　这里相对批量执行2，情况反而简单一些，不过就是循环处理@Execute注解，而每一个@Execute的处理，和批量执行1非常类型，先根据sqlRef属性方法确定执行的sqlId，然后根据@BatchParam确定对应的执行参数，不同于批量执行1的有几点：

  1. @BatchParam注解的value()属性方法起作用了，表示当前sqlId是否为一个子批量类型
  2. 求子批量类型的集合类型参数时，根对象不同了，批量执行1的根对象就是@BatchParam注解所在的入参，而批量执行3的根对象，是整个入参按照Mybatis原生方式组装的包装对象
  3. @Execute注解还包含condition()的属性方法，表示需要执行的条件表达式，如果为空，表示需要执行，这个条件表达式的求值根对象也是整个入参按照Mybatis原生方式组装的包装对象

　　到此，整个批量执行的三个基本问题也都已解决，但我们刚刚的说明有一个前提，那就是事先已经知道是什么批量类型了，而事实上，事先我们并不知道，那么怎么确定呢？

　　回过头来看，实际上已经很简单了，具体规则如下：

　　如果有@Executes注解，则为批量类型3；如果有@SqlRefs，则为批量类型2，其中含有@BatchParam注解的参数，则为批量类型2.1，否则为批量类型2.2；如果既没有@Executes，也没有@SqlRefs，则为批量类型1。

　　最后，动态代理接口扩展还剩下一个问题，那就是怎么使用我们的动态代理逻辑替换Mybatis的动态代理逻辑？跟踪源码就知道，Mybatis的动态代理逻辑主要在类org.apache.ibatis.binding.MapperMethod中，而这个类被MapperProxy调用，进而被org.apache.ibatis.session.Configuration所使用：

1 public class Configuration {
2
3 // ... 省略代码
4   protected MapperRegistry mapperRegistry = new MapperRegistry(this);
5 // ... 省略代码
6 }

因此，我们只需要继承Configuration，替换属性mapperRegistry的初始化即可，或者在运行时修改mapperRegistry的值也可以。

时间： 2024-08-04 07:40:05

Java EE开发平台随手记6——Mybatis扩展4的相关文章

Java EE开发平台随手记2——Mybatis扩展1

今天来记录一下对Mybatis的扩展,版本是3.3.0,是和Spring集成使用,mybatis-spring集成包的版本是1.2.3,如果使用maven,如下配置: <properties>元素下添加 1 <mybatis.version>3.3.0</mybatis.version> 2 <mybatis.spring.version>1.2.3</mybatis.spring.version> <dependencies>元素下

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

为了说明后续的Mybatis扩展,插播一篇广告,先来简要说明一下Mybatis的一种原生用法,不过先声明:下面说的只是Mybatis的其中一种用法,如需要更深入了解Mybatis,请参考官方文档,或者研读源码. 我们知道,使用Mybatis的方式有很多种,从是否集成上分,可以单独使用,也可以和Spring集成使用:从使用方式上分,可以编写静态工具类,在静态工具中调用SqlSession,也可以直接注入SqlSession/ SqlSessionTemplate,还可以编写Dao接口,让mybat

Java EE开发平台随手记1

过完春节以来,一直在负责搭建公司的新Java EE开发平台,所谓新平台,其实并不是什么新技术,不过是将目前业界较为流行的框架整合在一起,做一些简单的封装和扩展,让开发人员更加易用. 和之前负责具体的项目开发不同,不能只是功能实现就可以,还需要考虑更多的非功能性需求,比如性能.安全性.易用性.可维护性.易扩展性.兼容性等等,因此有很多在实际项目中觉得方便易用的功能不得不因种种原因而舍弃:另一方面,也常常会偶尔有一些新想法.新构想,但因缺乏实践论证,也往往没有加入进来:此外,对于平台中已经添加的那些

java快速开发平台可视化开发表单

XJR java快速开发平台,简单的理解就是:开发人员以某种编程语言或者某几种编程语言(比如:目前流行的多种web技术,包括springboot, JPA,Druid, Activiti,Lombok,swagger,poi,WebSocket,Jquery,BootStrap, maven,Jenkins 等等 )为基础,将各种需要的功能封装在不同的层中,具大家调用而开发出来的一个软件. 这个软件其实不是一个最终的软件产品,它是一个二次开发软件框架,用户可以在这个产品上进行各种各样的软件产品的

JAVA高速开发平台 - 开源 免费 - JEECG

JEECG 微云高速开发平台 当前最新版本号: 3.6.2(公布日期:20160315) 下载地址:http://git.oschina.net/jeecg/jeecg 前言: 随着 WEB UI 框架 ( EasyUI/Jquery UI/Ext/DWZ) 等的逐渐成熟,系统界面逐渐实现统一化,代码生成器也能够生成统一规范的界面! 代码生成+手工MERGE半智能开发将是新的趋势,单表数据模型和一对多数据模型的增删改查功能直接生成使用,可节省60%工作量,高速提高开发效率!! ! 简单介绍 JE

Java EE开发四大常用框架

我们对Java EE的框架有过很多介绍, 本文将对Java EE中常用的四个框架做一下系统的归纳,希望大家喜欢. Struts Struts是一个基于Sun Java EE平台的MVC框架,主要是采用Servlet和JSP技术来实现的. Struts框架可分为以下四个主要部分,其中三个就和MVC模式紧密相关: 1.模型 (Model),本质上来说在Struts中Model是一个Action类(这个会在后面详细讨论),开发者通过其实现商业逻辑,同时用户请求通过控制器(Controller)向Act

JAVA快速开发平台 - 开源 免费 - JEECG

JEECG 微云快速开发平台 当前最新版本: 3.6.2(发布日期:20160315) 下载地址:http://git.oschina.net/jeecg/jeecg 前言: 随着 WEB UI 框架 ( EasyUI/Jquery UI/Ext/DWZ) 等的逐渐成熟,系统界面逐渐实现统一化,代码生成器也可以生成统一规范的界面! 代码生成+手工MERGE半智能开发将是新的趋势,单表数据模型和一对多数据模型的增删改查功能直接生成使用,可节省60%工作量,快速提高开发效率!!! 简介 JEECG(

Java EE开发的四大框架

Java EE中最常用的四个框架分别是:Struts.Spring.Hibernate.Swing.下面就说说这四个框架的特点,希望大家喜欢. Struts Struts是一个基于Sun Java EE平台的MVC框架,主要是采用Servlet和JSP技术来实现的. Struts框架可分为以下四个主要部分,其中三个就和MVC模式紧密相关: 1.模型 (Model),本质上来说在Struts中Model是一个Action类(这个会在后面详细讨论),开发者通过其实现商业逻辑,同时用户请求通过控制器(

Java EE 开发环境搭建

下载安装Java EE SDK 版本:Java Platform,Enterprise Edition 7 SDK (with JDK 7u45) 下载页面: http://www.oracle.com/technetwork/java/javaee/downloads/java-ee-7-sdk-with-jdk-u45-2066865.html 文件名:java_ee_sdk-7-jdk7-windows.exe 安装路径:D:\glassfish4 环境变量设置 JAVA_HOME=D:\