Mybatis(四)：MyBatis核心組件介紹原理解析和源碼解讀

Mybatis核心成員

• Configuration        MyBatis所有的配置信息都保存在Configuration對象之中，配置文件中的大部分配置都會存儲到該類中
• SqlSession            作為MyBatis工作的主要頂層API，表示和數據庫交互時的會話，完成必要數據庫增刪改查功能
• Executor               MyBatis執行器，是MyBatis 調度的核心，負責SQL語句的生成和查詢緩存的維護
• StatementHandler 封裝了JDBC Statement操作，負責對JDBC statement 的操作，如設置參數等
• ParameterHandler  負責對用戶傳遞的參數轉換成JDBC Statement 所對應的數據類型
• ResultSetHandler   負責將JDBC返回的ResultSet結果集對象轉換成List類型的集合
• TypeHandler          負責java數據類型和jdbc數據類型(也可以說是數據表列類型)之間的映射和轉換
• MappedStatement  MappedStatement維護一條<select|update|delete|insert>節點的封裝
• SqlSource              負責根據用戶傳遞的parameterObject，動態地生成SQL語句，將信息封裝到BoundSql對象中，並返回
• BoundSql              表示動態生成的SQL語句以及相應的參數信息

以上主要成員在一次數據庫操作中基本都會涉及，在SQL操作中重點需要關注的是SQL參數什么時候被設置和結果集怎么轉換為JavaBean對象的，這兩個過程正好對應StatementHandler和ResultSetHandler類中的處理邏輯。

MyBatis啟動原理和源碼解析

1. SqlSessionFactory 與 SqlSession.

通過前面的章節對於mybatis 的介紹及使用，大家都能體會到SqlSession的重要性了吧， 沒錯，從表面上來看，咱們都是通過SqlSession去執行sql語句（注意：是從表面看，實際的待會兒就會講）。那么咱們就先看看是怎么獲取SqlSession的吧：

（1）首先，SqlSessionFactoryBuilder去讀取mybatis的配置文件，然后build一個DefaultSqlSessionFactory。

String resource = "mybatis.xml";

// 加載mybatis的配置文件（它也加載關聯的映射文件）
InputStream inputStream = null;
try {
    inputStream = Resources.getResourceAsStream(resource);
} catch (IOException e) {
    e.printStackTrace();
}

// 構建sqlSession的工廠
sessionFactory = new SqlSessionFactoryBuilder().build(inputStream);

源碼如下，首先會創建SqlSessionFactory建造者對象，然后由它進行創建SqlSessionFactory。這里用到的是建造者模式，建造者模式最簡單的理解就是不手動new對象，而是由其他類來進行對象的創建。更多建造模式學習參閱：設計模式之建造者模式學習理解

// SqlSessionFactoryBuilder類
public SqlSessionFactory build(InputStream inputStream, String environment, Properties properties) {
    try {
        XMLConfigBuilder parser = new XMLConfigBuilder(inputStream, environment, properties);
        return build(parser.parse()); // 開始進行解析了 :)
    } catch (Exception e) {
        throw ExceptionFactory.wrapException("Error building SqlSession.", e);
    } finally {
        ErrorContext.instance().reset();
        try {
            inputStream.close();
        } catch (IOException e) {
            // Intentionally ignore. Prefer previous error.
        }
    }
}

 通過以上步驟，咱們已經得到SqlSession對象了。接下來就是該干嘛干嘛去了（話說還能干嘛，當然是執行sql語句咯）。

SqlSession咱們也拿到了，咱們可以調用SqlSession中一系列的select...,  insert..., update..., delete...方法輕松自如的進行CRUD操作了。 就這樣？ 那咱配置的映射文件去哪兒了？  別急， 咱們接着往下看：

2. 利器之MapperProxy:

 

在mybatis中，通過MapperProxy動態代理咱們的dao， 也就是說， 當咱們執行自己寫的dao里面的方法的時候，其實是對應的mapperProxy在代理。那么，咱們就看看怎么獲取MapperProxy對象吧：

（1）通過SqlSession從Configuration中獲取。源碼如下：

/**
   * 什么都不做，直接去configuration中找， 哥就是這么任性
   */
  @Override
  public <T> T getMapper(Class<T> type) {
    return configuration.<T>getMapper(type, this);
  }

（2）SqlSession把包袱甩給了Configuration, 接下來就看看Configuration。源碼如下：

/**
   * 燙手的山芋，俺不要，你找mapperRegistry去要
   * @param type
   * @param sqlSession
   * @return
   */
  public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
    return mapperRegistry.getMapper(type, sqlSession);
  }

（3）Configuration不要這燙手的山芋，接着甩給了MapperRegistry， 那咱看看MapperRegistry。 源碼如下：

/**
   * 爛活凈讓我來做了，沒法了，下面沒人了，我不做誰來做
   * @param type
   * @param sqlSession
   * @return
   */
  @SuppressWarnings("unchecked")
  public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
    //能偷懶的就偷懶，俺把粗活交給MapperProxyFactory去做
    final MapperProxyFactory<T> mapperProxyFactory = (MapperProxyFactory<T>) knownMappers.get(type);
    if (mapperProxyFactory == null) {
      throw new BindingException("Type " + type + " is not known to the MapperRegistry.");
    }
    try {
      //關鍵在這兒
      return mapperProxyFactory.newInstance(sqlSession);
    } catch (Exception e) {
      throw new BindingException("Error getting mapper instance. Cause: " + e, e);
    }
  }

(4)MapperProxyFactory是個苦B的人，粗活最終交給它去做了。咱們看看源碼：

/**
   * 別人虐我千百遍，我待別人如初戀
   * @param mapperProxy
   * @return
   */
  @SuppressWarnings("unchecked")
  protected T newInstance(MapperProxy<T> mapperProxy) {
    //動態代理我們寫的dao接口
    return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[] { mapperInterface }, mapperProxy);
  }
  
  public T newInstance(SqlSession sqlSession) {
    final MapperProxy<T> mapperProxy = new MapperProxy<T>(sqlSession, mapperInterface, methodCache);
    return newInstance(mapperProxy);
  }

這里是關鍵，通過以上的動態代理（更多動態代理知識參閱：java中代理，靜態代理，動態代理以及spring aop代理方式，實現原理統一匯總 這篇文章里的動態代理章節），咱們就可以方便地使用dao接口啦， 就像之前咱們寫的demo那樣：

 UserDao userMapper = sqlSession.getMapper(UserDao.class);  
 User insertUser = new User();

這下方便多了吧， 呵呵， 貌似mybatis的源碼就這么一回事兒啊。

別急，還沒完， 咱們還沒看具體是怎么執行sql語句的呢。

3. Excutor:

接下來，咱們才要真正去看sql的執行過程了。

上面，咱們拿到了MapperProxy, 每個MapperProxy對應一個dao接口， 那么咱們在使用的時候，MapperProxy是怎么做的呢？ 源碼奉上：

MapperProxy:

/**
   * MapperProxy在執行時會觸發此方法
   */
  @Override
  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    if (Object.class.equals(method.getDeclaringClass())) {
      try {
        return method.invoke(this, args);
      } catch (Throwable t) {
        throw ExceptionUtil.unwrapThrowable(t);
      }
    }
    final MapperMethod mapperMethod = cachedMapperMethod(method);
    //二話不說，主要交給MapperMethod自己去管
    return mapperMethod.execute(sqlSession, args);
  }

MapperMethod:

/**
   * 看着代碼不少，不過其實就是先判斷CRUD類型，然后根據類型去選擇到底執行sqlSession中的哪個方法，繞了一圈，又轉回sqlSession了
   * @param sqlSession
   * @param args
   * @return
   */
  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 {
      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的CRUD方法了，為了省事，還是就選擇其中的一個方法來做分析吧。這兒，咱們選擇了selectList方法：

public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
    try {
      MappedStatement ms = configuration.getMappedStatement(statement);
      //CRUD實際上是交給Excetor去處理， excutor其實也只是穿了個馬甲而已，小樣，別以為穿個馬甲我就不認識你嘞！
      return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
    } catch (Exception e) {
      throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
    } finally {
      ErrorContext.instance().reset();
    }
  }

然后，通過一層一層的調用，最終會來到doQuery方法， 這兒咱們就隨便找個Excutor看看doQuery方法的實現吧，我這兒選擇了SimpleExecutor:

public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException {
    Statement stmt = null;
    try {
      Configuration configuration = ms.getConfiguration();
      StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
      stmt = prepareStatement(handler, ms.getStatementLog());
      //StatementHandler封裝了Statement, 讓 StatementHandler 去處理
      return handler.<E>query(stmt, resultHandler);
    } finally {
      closeStatement(stmt);
    }
  }

接下來，咱們看看StatementHandler 的一個實現類 PreparedStatementHandler（這也是我們最常用的，封裝的是PreparedStatement）, 看看它使怎么去處理的：

public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
     //到此，原形畢露， PreparedStatement, 這個大家都已經滾瓜爛熟了吧
    PreparedStatement ps = (PreparedStatement) statement;
    ps.execute();
    //結果交給了ResultSetHandler 去處理
    return resultSetHandler.<E> handleResultSets(ps);
  }

到此， 一次sql的執行流程就完了。