mybatis(十)SQL執行流程分析(源碼篇)

1. SqlSessionFactory 與 SqlSession. java

  經過前面的章節對於mybatis 的介紹及使用,你們都能體會到SqlSession的重要性了吧, 沒錯,從表面上來看,我們都是經過SqlSession去執行sql語句(注意:是從表面看,實際的待會兒就會講)。那麼我們就先看看是怎麼獲取SqlSession的吧: sql

(1)首先,SqlSessionFactoryBuilder去讀取mybatis的配置文件,而後build一個DefaultSqlSessionFactory。源碼以下: session


/**
   * 一系列的構造方法最終都會調用本方法(配置文件爲Reader時會調用本方法,還有一個InputStream方法與此對應)
   * @param reader
   * @param environment
   * @param properties
   * @return
   */
  public SqlSessionFactory build(Reader reader, String environment, Properties properties) {
    try {
      //經過XMLConfigBuilder解析配置文件,解析的配置相關信息都會封裝爲一個Configuration對象
      XMLConfigBuilder parser = new XMLConfigBuilder(reader, environment, properties);
      //這兒建立DefaultSessionFactory對象
      return build(parser.parse());
    } catch (Exception e) {
      throw ExceptionFactory.wrapException("Error building SqlSession.", e);
    } finally {
      ErrorContext.instance().reset();
      try {
        reader.close();
      } catch (IOException e) {
        // Intentionally ignore. Prefer previous error.
      }
    }
  }

  public SqlSessionFactory build(Configuration config) {
    return new DefaultSqlSessionFactory(config);
  }



(2)當咱們獲取到SqlSessionFactory以後,就能夠經過SqlSessionFactory去獲取SqlSession對象。源碼以下:



/**
   * 一般一系列openSession方法最終都會調用本方法
   * @param execType 
   * @param level
   * @param autoCommit
   * @return
   */
  private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {
    Transaction tx = null;
    try {
      //經過Confuguration對象去獲取Mybatis相關配置信息, Environment對象包含了數據源和事務的配置
      final Environment environment = configuration.getEnvironment();
      final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment);
      tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit);
      //以前說了,從表面上來看,我們是用sqlSession在執行sql語句, 實際呢,實際上是經過excutor執行, excutor是對於Statement的封裝
      final Executor executor = configuration.newExecutor(tx, execType);
      //關鍵看這兒,建立了一個DefaultSqlSession對象
      return new DefaultSqlSession(configuration, executor, autoCommit);
    } catch (Exception e) {
      closeTransaction(tx); // may have fetched a connection so lets call close()
      throw ExceptionFactory.wrapException("Error opening session.  Cause: " + e, e);
    } finally {
      ErrorContext.instance().reset();
    }
  }



經過以上步驟,我們已經獲得SqlSession對象了。接下來就是該幹嗎幹嗎去了(話說還能幹嗎,固然是執行sql語句咯)。看了上面,我們也回想一下以前寫的Demo, 



SqlSessionFactory sqlSessionFactory = null;
		String resource = "./configuration.xml";
		try {
			sqlSessionFactory = new SqlSessionFactoryBuilder().build(Resources.getResourceAsReader(resource));
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		return sqlSessionFactory;
//經過SqlSessionFactory獲取SqlSession SqlSession sqlSession = sessionFactory.openSession();

還真這麼一回事兒,對吧! mybatis

SqlSession我們也拿到了,我們能夠調用SqlSession中一系列的select..., insert..., update..., delete...方法輕鬆自如的進行CRUD操做了。 就這樣? 那咱配置的映射文件去哪兒了? 別急, 我們接着往下看: app

2. 利器之MapperProxy: ide

在mybatis中,經過MapperProxy動態代理我們的dao, 也就是說, 當我們執行本身寫的dao裏面的方法的時候,實際上是對應的mapperProxy在代理。那麼,我們就看看怎麼獲取MapperProxy對象吧: fetch

(1)經過SqlSession從Configuration中獲取。源碼以下: ui

/**
   * 什麼都不作,直接去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);
  }



經過以上的動態代理,我們就能夠方便地使用dao接口啦, 就像以前我們寫的demo那樣: this

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

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

別急,還沒完, 我們還沒看具體是怎麼執行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的執行流程就完了。
相關文章
相關標籤/搜索