mybatis框架在操作數(shù)據(jù)的時(shí)候，離不開SqlSession接口實(shí)例類的作用?？梢哉fSqlSession接口實(shí)例是開發(fā)過程中打交道最多的一個(gè)類。即是DefaultSqlSession類。如果筆者記得沒有錯(cuò)的話，早期是沒有什么getMapper方法的。增刪改查各志有對應(yīng)的方法進(jìn)行操作。雖然現(xiàn)在改進(jìn)了很多，但是也保留了很多。我們依舊可以看到類似于selectList這樣子的方法。源碼的例子里面就可以找到。如下

SqlSession session = sqlMapper.openSession(TransactionIsolationLevel.SERIALIZABLE);
  try {
   List<Author> authors = session.selectList("org.apache.ibatis.domain.blog.mappers.AuthorMapper.selectAllAuthors");
   assertEquals(2, authors.size());
  } finally {
   session.close();

當(dāng)然從某種意義上來講，寫起有一點(diǎn)煩。但是不可否認(rèn)他的功能的確存在。這也是筆者為什么比較喜歡用動態(tài)代理來進(jìn)行數(shù)據(jù)上的操作。至少可觀性上筆者認(rèn)為比較好吧。

不管是哪一種數(shù)據(jù)上的操作都離不開SqlSession接口實(shí)例。所以深入查看qlSession接口實(shí)例就顯得相當(dāng)?shù)闹匾９P者選擇了DefaultSqlSession類的selectList方法作為入口點(diǎn)進(jìn)行切入。代碼如下。

public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
  try {
   MappedStatement ms = configuration.getMappedStatement(statement);
   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();
  }
 }

源碼的意思是從configuration變理里面獲得，在通過Executor類的query方法獲得相應(yīng)的結(jié)果。讓我們想想上一章中講過MappedStatement類是用于存放select節(jié)點(diǎn)或是update節(jié)點(diǎn)的信息。也就是說這里傳入statement參數(shù)表示將要去執(zhí)行哪一個(gè)select節(jié)點(diǎn)。傳入的參數(shù)自然就是select節(jié)點(diǎn)id對應(yīng)的值。那么Executor類又是什么。如果比較認(rèn)真的人來查看源碼的話，你會發(fā)現(xiàn)基本上都會用到Executor類實(shí)例。在一次嘆氣——架構(gòu)之美。

DefaultSqlSession類的成員executor是在構(gòu)造函數(shù)里面給他賦值的。所以我們又要回頭去查看一下是在什么時(shí)候?qū)嵗薉efaultSqlSession類。筆者在第一章結(jié)尾的時(shí)候也講到過關(guān)于Executor類。從源碼中我們可以看到他是通過Configuration類的newExecutor方法來得到的。代碼如下

public Executor newExecutor(Transaction transaction, ExecutorType executorType) {
  executorType = executorType == null ? defaultExecutorType : executorType;
  executorType = executorType == null ? ExecutorType.SIMPLE : executorType;
  Executor executor;
  if (ExecutorType.BATCH == executorType) {
   executor = new BatchExecutor(this, transaction);
  } else if (ExecutorType.REUSE == executorType) {
   executor = new ReuseExecutor(this, transaction);
  } else {
   executor = new SimpleExecutor(this, transaction);
  }
  if (cacheEnabled) {
   executor = new CachingExecutor(executor);
  }
  executor = (Executor) interceptorChain.pluginAll(executor);
  return executor;
 }

 完了。沒有想到Executor類還有分種類的。說實(shí)話筆者若是沒有去查看源碼真不會知道原來Executor類還有分種類的。看上面的源碼筆者剛開始認(rèn)為有四種。但是發(fā)現(xiàn)最后一個(gè)跟上面的三個(gè)實(shí)例上有一點(diǎn)不同。為了更進(jìn)一步確認(rèn)筆者不得不去查看一下官網(wǎng)上面的API。筆者把內(nèi)容復(fù)制過來。如下。

ExecutorType.SIMPLE: 這個(gè)執(zhí)行器類型不做特殊的事情。它為每個(gè)語句的執(zhí)行創(chuàng)建一個(gè)新的預(yù)處理語句。

ExecutorType.REUSE: 這個(gè)執(zhí)行器類型會復(fù)用預(yù)處理語句。

ExecutorType.BATCH: 這個(gè)執(zhí)行器會批量執(zhí)行所有更新語句,如果 SELECT 在它們中間執(zhí)行還會標(biāo)定它們是 必須的,來保證一個(gè)簡單并易于理解的行為。

看樣子官網(wǎng)解釋的很清楚了。筆者就不在這里多言了。那么默認(rèn)情況下mybatis框架又是調(diào)用哪一個(gè)Executor子類呢？其實(shí)這一點(diǎn)是可以在源碼上找到的。如下

Configuration類：

protected ExecutorType defaultExecutorType = ExecutorType.SIMPLE;

相信大家都明白了如果都沒有指定相應(yīng)的Executor類的類型的話，mybatis框架會去調(diào)用SimpleExecutor類。

對于Executor類我先了解到這里。因?yàn)楹竺娲罅恳玫剿瑫r(shí)也只有結(jié)合后面的功能才明白Executor類的作用。從上面DefaultSqlSession類的selectList方法中我們可以發(fā)現(xiàn)最后會去調(diào)用Executor類的query方法。

return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);

對于變量ms筆者就不多說了。wrapCollection方法卻是值得注意的。他意思是先判斷變理parameter是否是Collection類型，如果是，就是新建一個(gè)StrictMap類型并以“collection”為key進(jìn)行存放。又查一下是不是List類型。如果是，就以“l(fā)ist”為key進(jìn)行存放。接下就是判斷是不是數(shù)組類型，如果是，就是新建一個(gè)StrictMap類型并以“array”為key進(jìn)行存放。最后返回回StrictMap類實(shí)例。當(dāng)然如果上面都不是的話，就直接返回parameter了。如果不清楚為什么設(shè)計(jì)者要這樣子做不要緊，筆者這個(gè)時(shí)候也不知道為什么。所以筆者只要記得他做了什么。RowBounds類型變理rowBounds一般用于分頁。默認(rèn)是0到2147483647值，相信這個(gè)夠你用了吧。ResultHandler是用于處理返回的結(jié)果，這里直接就不要處理返回的結(jié)果了。所以筆者就不用講了。

BaseExecutor類：

 public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
  BoundSql boundSql = ms.getBoundSql(parameter);
  CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql);
  return query(ms, parameter, rowBounds, resultHandler, key, boundSql);
 }

類似于SimpleExecutor這樣子類并不是直接的繼承了Executor類。而是通過BaseExecutor類這一層之后到繼承Executor類。所以query方法調(diào)用的時(shí)候并不是調(diào)用SimpleExecutor類的。而是調(diào)用BaseExecutor類的。當(dāng)然你從SimpleExecutor類也找不到query方法。顯然是經(jīng)過BaseExecutor類進(jìn)行處理相關(guān)的信息之后，在去調(diào)用Executor子類的doQuery方法。所以我們可以找到SimpleExecutor類的doQuery方法。這個(gè)過程筆者就不想細(xì)說。筆者主要目地還是引導(dǎo)大家去看的。

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());
   return handler.<E>query(stmt, resultHandler) ; 
  } finally {
   closeStatement(stmt);
  }
 }

  從源碼上來看筆者只認(rèn)識倆個(gè)類一個(gè)是Configuration類和Statement類。Statement類是屬于JDBC的知識點(diǎn)。Configuration類是屬于mybatis框架的配置信息部分。意思就是通過MappedStatement獲得Configuration類的信息。在通過Configuration類新建StatementHandler接口實(shí)例。而StatementHandler接口實(shí)例就是用來處理生成Statement類的。很明顯就是執(zhí)行SQL語句就是在StatementHandler接口實(shí)例里面。

筆者來一個(gè)小結(jié)：動態(tài)代理的方式事實(shí)上最后還是動用SqlSession接口實(shí)例的方法。所以只有了解了SqlSession接口實(shí)例的方法就是可以進(jìn)一步深入。而SqlSession接口實(shí)例執(zhí)行方法的過程中又會去執(zhí)行Executor類的方法。而關(guān)于Configuration類的作用可以說是任務(wù)時(shí)候都有可以初動用。當(dāng)前最后的任務(wù)暫時(shí)是交給了Executor類的子類。

好了。到了這里面，關(guān)于SqlSession接口和Executor類的作用就有一個(gè)大概的像想空間。當(dāng)然只望一下就明白SqlSession接口和Executor類的話，筆者覺得有一點(diǎn)難。至少筆者沒有這樣子的能力。在筆者看來SqlSession接口和Executor類的工作在doQuery方法的時(shí)候，就已經(jīng)圓完的結(jié)束了。雖然筆者并沒有說出SqlSession接口和Executor類的作用。主要還是靠你們自己去理解了。接下就來就是了解一下StatementHandler接口的作用。

以上所述是小編給大家介紹的MyBatis 源碼分析 之SqlSession接口和Executor類，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時(shí)回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！

最新評論