Mybatis(四):MyBatis核心元件介紹原理解析和原始碼解讀 java中代理,靜態代理,動態代理以及spring aop代理方式,實現原理統一彙總
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的執行流程就完了。