Mybatis源码解析(三) —— Mapper代理类的生成

Mybatis源码解析(三) —— Mapper代理类的生成

  在本系列第一篇文章已经讲述过在Mybatis-Spring项目中,是通过 MapperFactoryBean 的 getObject()方法来获取到Mapper的代理类并注入到Spring容器中的。在学习本章之前我们先提出以下几点问题:

  • 1、 Mapper接口是如何被加载 到 Configuration 中的?
  • 2、 Mapper代理类是如何生成的?
  • 3、 Mapper代理类是如何实现接口方法的?

   本章内容就是围绕着上面三个问题进行解析,那么带着问题去看源码吧!

一、加载 Mapper接口

  针对Mybatis项目,Mapper的配置加载是从XmlConfigBuilder.mapperElement()方法中触发的。我们来看下源码:

  private void mapperElement(XNode parent) throws Exception {
    if (parent != null) {
      for (XNode child : parent.getChildren()) {
        if ("package".equals(child.getName())) {
          // 通过  package 形式加载 ,内部其实也是获取到 package 路径下的所有class再通过  class 形式加载
          String mapperPackage = child.getStringAttribute("name");
          configuration.addMappers(mapperPackage);
        } else {
          String resource = child.getStringAttribute("resource");
          String url = child.getStringAttribute("url");
          String mapperClass = child.getStringAttribute("class");
          if (resource != null && url == null && mapperClass == null) {
            // 加载 Mapper.xml 的
            ErrorContext.instance().resource(resource);
            InputStream inputStream = Resources.getResourceAsStream(resource);
            XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration, resource, configuration.getSqlFragments());
            mapperParser.parse();
          } else if (resource == null && url != null && mapperClass == null) {
            // 加载 Mapper.xml 的
            ErrorContext.instance().resource(url);
            InputStream inputStream = Resources.getUrlAsStream(url);
            XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration, url, configuration.getSqlFragments());
            mapperParser.parse();
          } else if (resource == null && url == null && mapperClass != null) {
            // 通过  class 形式加载
            Class mapperInterface = Resources.classForName(mapperClass);
            configuration.addMapper(mapperInterface);
          } else {
            throw new BuilderException("A mapper element may only specify a url, resource or class, but not more than one.");
          }
        }
      }
    }
  }
        

从上面源码看,加载Mapper接口有2种形式: 一种是根据设置的 package 找到路径下面所有的class并通过configuration.addMapper() 加载。 另一种是根据指定设置的Mapper接口路径直接通过 configuration.addMapper()加载class。所以加载Mapper接口最终都是 configuration.addMapper() 来加载的。

  而针对Mybatis-Spring项目则是 获取 MapperScannerConfigurer 的 basePackage 参数,并通过 ClassPathMapperScanner 扫描到 设置的 basePackage 路径下的所有class ,并得到 BeanDefinition ,后面的情况在第一篇文章已经讲过,最终是得到了 MapperFactoryBean ,并且还到了 MapperFactoryBean 内部的 checkDaoConfig() 方法加载Mapper接口的内容,那么我们再次回顾下这个方法的源码:


  @Override
  protected void checkDaoConfig() {
    super.checkDaoConfig();

    notNull(this.mapperInterface, "Property 'mapperInterface' is required");

    Configuration configuration = getSqlSession().getConfiguration();
    if (this.addToConfig && !configuration.hasMapper(this.mapperInterface)) {
      try {
        // 最终都是通过 addMapper() 方法加载的。
        configuration.addMapper(this.mapperInterface);
      } catch (Throwable t) {
        logger.error("Error while adding the mapper '" + this.mapperInterface + "' to configuration.", t);
        throw new IllegalArgumentException(t);
      } finally {
        ErrorContext.instance().reset();
      }
    }
  }
 

   从源码中我们发现 内部其实还是通过 configuration.addMapper() 加载的。可能有些同学会问,checkDaoConfig()什么时候被调用的,这个可以追溯到 MapperFactoryBean 的继承关系图,可以发现实现了 InitializingBean接口, 而 checkDaoConfig() 就是 通过afterPropertiesSet() 调用的。所以在MapperFactoryBean 初始化创建的时候就会调用checkDaoConfig(),即 加载Mapper接口。

   根据上面的分析,我们可以发现 configuration.addMapper() 是实现加载Mapper接口的最核心的方法,那么我们就来好好分析下这个方法内部实现源码:


  public  void addMapper(Class type) {
    mapperRegistry.addMapper(type);
  }
  

  其内部是通过 委托 mapperRegistry 来就行加载的,那继续往下看:


  public  void addMapper(Class type) {
    // 1、 判断是否为接口
    if (type.isInterface()) {
      // 2、 判断是否已加载
      if (hasMapper(type)) {
        throw new BindingException("Type " + type + " is already known to the MapperRegistry.");
      }
      boolean loadCompleted = false;
      try {
        // 3、 将 Mapper的class作为 MapperProxyFactory(生成Mapper代理对象的工厂类) 的构参,并保存到 knownMappers 中。
        knownMappers.put(type, new MapperProxyFactory(type));
        // 4、 解析 Class对象中,包含的所有mybatis框架中定义的注解,并生成Cache、ResultMap、MappedStatement。
        MapperAnnotationBuilder parser = new MapperAnnotationBuilder(config, type);
        parser.parse();
        loadCompleted = true;
      } finally {
        if (!loadCompleted) {
          knownMappers.remove(type);
        }
      }
    }
  }

   根据源码可以把整个加载流程分4个步骤:

  • 1、 判断是否为接口
  • 2、 判断是否已加载
  • 3、 将 Mapper的class作为 MapperProxyFactory(生成Mapper代理对象的工厂类) 的构参,并保存到 knownMappers 中。
  • 4、 解析 Class对象中,包含的所有mybatis框架中定义的注解,并生成Cache、ResultMap、MappedStatement。

   其中第三步是加载Mapper的核心,也就是同创建了一个生成Mapper代理对象的工厂对象,并将其放到map,等需要创建Mapper代理对象的是再通过获取map中的工厂对象即可。 关于第四步,就是最近几年比较流行的通过注解编写SQl形式的解析方法。我们知道mybatis支持xml和注解形式的Sql编写。所以 MapperAnnotationBuilder 就是解析注解形式,根解析xml一样, 最终也会生成 ResultMap、MappedStatement对象封装到 configuration 中。关于它是如何解析的,有兴趣的同学可以看啊可能源码,这里不在描述。

二、 Mapper动态代理对象(MapperProxy)的创建

   通过之前的文章,我们知道 MapperFactoryBean 实现了 FactoryBean,也就是说在Spring 根据BeanDefinition 加载Bean的时候会调用 MapperFactoryBean.getObject() 获取真实的Bean并注入到容器中。不用想,getObject()获取到的一定是Mapper接口的代理实现类 MapperProxy,那么我们来一步步分析是如何创建 MapperProxy


  public T getObject() throws Exception {
    return getSqlSession().getMapper(this.mapperInterface);
  }
  

   getObject()方法是通过 getSqlSession().getMapper() 获取到 MapperProxy 的,相信大家对这个不陌生吧。至于这里的SqlSession 其实是 SqlSessionTemplate ,这个之前也讲过,所以继续查看:


  public  T getMapper(Class type) {
    return getConfiguration().getMapper(type, this);
  }
  

   最终还是通过 configuration().getMapper() 获取到 MapperProxy。继续查看:


  public  T getMapper(Class type, SqlSession sqlSession) {
    return mapperRegistry.getMapper(type, sqlSession);
  }
  

   毫不意外的肯定是委托 mapperRegistry.getMapper() 来获取,继续查看:


  public  T getMapper(Class type, SqlSession sqlSession) {
    // 1、 从 knownMappers 中获取到  MapperProxyFactory 
    final MapperProxyFactory mapperProxyFactory = (MapperProxyFactory) knownMappers.get(type);
    if (mapperProxyFactory == null)
      throw new BindingException("Type " + type + " is not known to the MapperRegistry.");
    try {
      // 2、 通过  mapperProxyFactory.newInstance() 创建 MapperProxy
      return mapperProxyFactory.newInstance(sqlSession);
    } catch (Exception e) {
      throw new BindingException("Error getting mapper instance. Cause: " + e, e);
    }
  }
  

   也毫不意外的是 从 knownMappers 中获取到 MapperProxyFactory ,再 通过 mapperProxyFactory.newInstance() 创建 MapperProxy。 继续查看 mapperProxyFactory.newInstance() 内部实现:


  @SuppressWarnings("unchecked")
  protected T newInstance(MapperProxy mapperProxy) {
    return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[] { mapperInterface }, mapperProxy);
  }

  public T newInstance(SqlSession sqlSession) {
    final MapperProxy mapperProxy = new MapperProxy(sqlSession, mapperInterface, methodCache);
    return newInstance(mapperProxy);
  }

   从上面源码可以清晰的看到 Proxy.newProxyInstance() 指定了被代理的类是 mapperInterface,其代理类是 mapperProxy,所以最终动态创建出 mapperInterface 的动态代理类 MapperProxy@xxxx (动态代理类名)

三、 MapperProxy 接口方法的实现

  通过上面的解析,我们明确了 MapperProxy 代理是通过JDK动态生成,但接口方法是如何实现的呢? 这里就得看 MapperProxy 源码:


public class MapperProxy implements InvocationHandler, Serializable {

  private static final long serialVersionUID = -6424540398559729838L;
  // 注意: 这个 SqlSession 实际上是 SqlSessionTemplate
  private final SqlSession sqlSession;
  private final Class mapperInterface;
  private final Map methodCache;

  public MapperProxy(SqlSession sqlSession, Class mapperInterface, Map methodCache) {
    this.sqlSession = sqlSession;
    this.mapperInterface = mapperInterface;
    this.methodCache = methodCache;
  }

  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    // 如果调用的方法是 Object 种定义的方法,直接执行
    if (Object.class.equals(method.getDeclaringClass())) {
      try {
        return method.invoke(this, args);
      } catch (Throwable t) {
        throw ExceptionUtil.unwrapThrowable(t);
      }
    }
    // 接口方法的调用都是通过 MapperMethod 来执行的
    final MapperMethod mapperMethod = cachedMapperMethod(method);
    return mapperMethod.execute(sqlSession, args);
  }

  // Mapper接口的每个方法 都会生成一个 MapperMethod 对象,并通过 methodCache 来维护它们之间的关系
  private MapperMethod cachedMapperMethod(Method method) {
    MapperMethod mapperMethod = methodCache.get(method);
    if (mapperMethod == null) {
      // 注意这里 传入了 要执行的 方法信息
      mapperMethod = new MapperMethod(mapperInterface, method, sqlSession.getConfiguration());
      methodCache.put(method, mapperMethod);
    }
    return mapperMethod;
  }

}

  从上面源码中,我们可以发现,接口方法的实现其实是通过 MapperMethod 来实现的,且 Mapper接口的每个方法 都会生成一个 MapperMethod 对象,并通过 methodCache 来维护它们之间的关系,而 methodCache 是通过 MapperProxyFactory 传递下来的。

MapperMethod

   MapperMethod 实现接口方法的入口是 execute()方法,我们来看下其内部源码:

  // 实际上都是调用 SqlSession的方法实现
  public Object execute(SqlSession sqlSession, Object[] args) {
    Object result;
    // 判断 索要执行的方法类型
    if (SqlCommandType.INSERT == command.getType()) {
      // 参数转换
      Object param = method.convertArgsToSqlCommandParam(args);
      // 执行insert
      result = rowCountResult(sqlSession.insert(command.getName(), param));
    } else if (SqlCommandType.UPDATE == command.getType()) {
      Object param = method.convertArgsToSqlCommandParam(args);
      // 执行 update
      result = rowCountResult(sqlSession.update(command.getName(), param));
    } else if (SqlCommandType.DELETE == command.getType()) {
      Object param = method.convertArgsToSqlCommandParam(args);
      // 执行 delete
      result = rowCountResult(sqlSession.delete(command.getName(), param));
    } else if (SqlCommandType.SELECT == command.getType()) {
      // 执行 select
      if (method.returnsVoid() && method.hasResultHandler()) {
        // 没有返回
        executeWithResultHandler(sqlSession, args);
        result = null;
      } else if (method.returnsMany()) {
        // 返回 List
        result = executeForMany(sqlSession, args);
      } else if (method.returnsMap()) {
        // 返回 Map
        result = executeForMap(sqlSession, args);
      } else {
        // 返回 一个对象
        Object param = method.convertArgsToSqlCommandParam(args);
        result = sqlSession.selectOne(command.getName(), param);
      }
    } 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;
  }

   根据源码我们可以发现其实内部都是 委托 SqlSession 的方法实现的,但它是如何区别什么时候调用哪个 SqlSession 的方法呢?这个就不得不说 MapperMethod 内部维护的 SqlCommand 对象,我们查看 SqlCommand 的构造方法:


 public SqlCommand(Configuration configuration, Class mapperInterface, Method method) throws BindingException {
      // 补全 方法的全名称路径 即 com.xxx.selectByName 
      String statementName = mapperInterface.getName() + "." + method.getName();
      MappedStatement ms = null;
      // 从 configuration 中获取到 MappedStatement 对象
      if (configuration.hasStatement(statementName)) {
        ms = configuration.getMappedStatement(statementName);
      } else if (!mapperInterface.equals(method.getDeclaringClass().getName())) { // issue #35
        String parentStatementName = method.getDeclaringClass().getName() + "." + method.getName();
        if (configuration.hasStatement(parentStatementName)) {
          ms = configuration.getMappedStatement(parentStatementName);
        }
      }
      if (ms == null) {
        throw new BindingException("Invalid bound statement (not found): " + statementName);
      }
      // 从 MappedStatement 中获取到方法名 (注意: 节点中的id属性包含命名空间)
      name = ms.getId();
      // 从 MappedStatement 中获取到 方法的节点标签,即 select|insert|update|delete
      type = ms.getSqlCommandType();
      if (type == SqlCommandType.UNKNOWN) {
        throw new BindingException("Unknown execution method for: " + name);
      }
    }

   我们通过分析知道 ,SqlCommand 其实是通过从 MappedStatement 中获取到 方法名,以及所要执行的SQl命令类型(select|insert|update|delete)。 这里我们可以明确的发现从configuration 中 获取 MappedStatement 是通过 全称路径的方法去获取的,即 com.xxx.selectByName 这种,调用SqlSession的方法虽然是从 MappedStatement 中获取 id (注意: 节点中的id属性包含命名空间),但实质上都是 com.xxx.selectByName。但我们可以通过这里看出mybatis的Mapper接口方法是不可以重载的。

四、 个人总结

  • 1、 Configuration 维护了一个 MapperRegistry 对象,该对象主要作用就是加载Mapper接口和获取MapperProxy。
  • 2、 MapperRegistry 维护了一个key为 mapper接口class对象,value为 MapperProxyFactory 的map
  • 3、 MapperProxy 是 通过 MapperProxyFactory 创建的。
  • 4、 MapperProxy 实现 Mapper接口方法是委托 MapperMethod 执行的。
  • 5、 MapperMethod 执行接口方法时是通过 SqlCommand 来判断要执行的具体 SQL节点,并且最终委托 SqlSession执行。
  • 6、 SqlCommand 内部的 信息是通过从 MappedStatement 中获取的。

         如果您对这些感兴趣,欢迎star、follow、收藏、转发给予支持!

本文由博客一文多发平台 OpenWrite 发布!

你可能感兴趣的:(java)