@java
前面幾篇文章分析了Mybatis的核心原理,但模塊較多,沒有一一分析,更多的須要讀者本身下來研究。不過Mybatis的插件擴展機制仍是很是重要的,像PageHelper就是一個擴展插件,熟悉其擴展原理,才能更好的針對咱們的業務做出更合適的擴展。另外,如今Mybatis都是和Spring/SpringBoot一塊兒使用,那麼Mybatis又是如何與它們進行整合的呢?一切答案盡在本文之中。spring
熟悉Mybatis配置的都知道,在xml配置中咱們能夠配置以下節點:sql
<plugins> <plugin interceptor="org.apache.ibatis.builder.ExamplePlugin"> <property name="pluginProperty" value="100"/> </plugin> </plugins>
這個就是插件的配置,那麼天然而然的這個節點就會在解析xml的時候進行解析,並將其添加到Configuration中。細心的讀者應該還記得下面這段代碼,在XMLConfigBuilderl類中:數據庫
private void parseConfiguration(XNode root) { try { //issue #117 read properties first //解析<properties>節點 propertiesElement(root.evalNode("properties")); //解析<settings>節點 Properties settings = settingsAsProperties(root.evalNode("settings")); loadCustomVfs(settings); //解析<typeAliases>節點 typeAliasesElement(root.evalNode("typeAliases")); //解析<plugins>節點 pluginElement(root.evalNode("plugins")); //解析<objectFactory>節點 objectFactoryElement(root.evalNode("objectFactory")); //解析<objectWrapperFactory>節點 objectWrapperFactoryElement(root.evalNode("objectWrapperFactory")); //解析<reflectorFactory>節點 reflectorFactoryElement(root.evalNode("reflectorFactory")); settingsElement(settings);//將settings填充到configuration // read it after objectFactory and objectWrapperFactory issue #631 //解析<environments>節點 environmentsElement(root.evalNode("environments")); //解析<databaseIdProvider>節點 databaseIdProviderElement(root.evalNode("databaseIdProvider")); //解析<typeHandlers>節點 typeHandlerElement(root.evalNode("typeHandlers")); //解析<mappers>節點 mapperElement(root.evalNode("mappers")); } catch (Exception e) { throw new BuilderException("Error parsing SQL Mapper Configuration. Cause: " + e, e); } }
其中pluginElement就是解析插件節點的:apache
private void pluginElement(XNode parent) throws Exception { if (parent != null) { //遍歷全部的插件配置 for (XNode child : parent.getChildren()) { //獲取插件的類名 String interceptor = child.getStringAttribute("interceptor"); //獲取插件的配置 Properties properties = child.getChildrenAsProperties(); //實例化插件對象 Interceptor interceptorInstance = (Interceptor) resolveClass(interceptor).newInstance(); //設置插件屬性 interceptorInstance.setProperties(properties); //將插件添加到configuration對象,底層使用list保存全部的插件並記錄順序 configuration.addInterceptor(interceptorInstance); } } }
從上面能夠看到,就是根據配置實例化爲Interceptor對象,並添加到InterceptorChain中,該類的對象被Configuration持有。Interceptor包含三個方法:數組
//執行攔截邏輯的方法 Object intercept(Invocation invocation) throws Throwable; //target是被攔截的對象,它的做用就是給被攔截的對象生成一個代理對象 Object plugin(Object target); //讀取在plugin中設置的參數 void setProperties(Properties properties);
而InterceptorChain只是保存了全部的Interceptor,並提供方法給客戶端調用,使得全部的Interceptor生成代理對象:緩存
public class InterceptorChain { private final List<Interceptor> interceptors = new ArrayList<>(); public Object pluginAll(Object target) { for (Interceptor interceptor : interceptors) { target = interceptor.plugin(target); } return target; } public void addInterceptor(Interceptor interceptor) { interceptors.add(interceptor); } public List<Interceptor> getInterceptors() { return Collections.unmodifiableList(interceptors); } }
能夠看到pluginAll就是循環去調用了Interceptor的plugin方法,而該方法的實現通常是經過Plugin.wrap去生成代理對象:session
public static Object wrap(Object target, Interceptor interceptor) { //解析Interceptor上@Intercepts註解獲得的signature信息 Map<Class<?>, Set<Method>> signatureMap = getSignatureMap(interceptor); Class<?> type = target.getClass();//獲取目標對象的類型 Class<?>[] interfaces = getAllInterfaces(type, signatureMap);//獲取目標對象實現的接口 if (interfaces.length > 0) { //使用jdk的方式建立動態代理 return Proxy.newProxyInstance( type.getClassLoader(), interfaces, new Plugin(target, interceptor, signatureMap)); } return target; }
其中getSignatureMap就是將@Intercepts註解中的value值解析並緩存起來,該註解的值是@Signature類型的數組,而這個註解能夠定義class類型、方法、參數,即攔截器的定位。而getAllInterfaces就是獲取要被代理的接口,而後經過JDK動態代理建立代理對象,能夠看到InvocationHandler就是Plugin類,因此直接看invoke方法,最終就是調用interceptor.intercept方法:mybatis
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { try { //獲取當前接口能夠被攔截的方法 Set<Method> methods = signatureMap.get(method.getDeclaringClass()); if (methods != null && methods.contains(method)) {//若是當前方法須要被攔截,則調用interceptor.intercept方法進行攔截處理 return interceptor.intercept(new Invocation(target, method, args)); } //若是當前方法不須要被攔截,則調用對象自身的方法 return method.invoke(target, args); } catch (Exception e) { throw ExceptionUtil.unwrapThrowable(e); } }
這裏的插件實現思路是通用的,即這個interceptor咱們能夠用來擴展任何對象的任何方法,好比對Map的get進行攔截,可像下面這樣實現:app
@Intercepts({ @Signature(type = Map.class, method = "get", args = {Object.class})}) public static class AlwaysMapPlugin implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { return "Always"; } @Override public Object plugin(Object target) { return Plugin.wrap(target, this); } @Override public void setProperties(Properties properties) { } }
而後在使用Map時先用插件對其包裝,這樣拿到的就是Map的代理對象。
Map map = new HashMap(); map = (Map) new AlwaysMapPlugin().plugin(map);
由於咱們能夠對Mybatis擴展任意多個的插件,因此它使用InterceptorChain對象來保存全部的插件,這是責任鏈模式的實現。那麼Mybatis到底會攔截哪些對象和哪些方法呢?回憶上篇文章咱們就能夠發現Mybatis只會對如下4個對象進行攔截:
public Executor newExecutor(Transaction transaction, ExecutorType executorType) { ......省略 //經過interceptorChain遍歷全部的插件爲executor加強,添加插件的功能 executor = (Executor) interceptorChain.pluginAll(executor); return executor; }
public StatementHandler newStatementHandler(Executor executor, MappedStatement mappedStatement, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) { //建立RoutingStatementHandler對象,實際由statmentType來指定真實的StatementHandler來實現 StatementHandler statementHandler = new RoutingStatementHandler(executor, mappedStatement, parameterObject, rowBounds, resultHandler, boundSql); statementHandler = (StatementHandler) interceptorChain.pluginAll(statementHandler); return statementHandler; }
public ParameterHandler newParameterHandler(MappedStatement mappedStatement, Object parameterObject, BoundSql boundSql) { ParameterHandler parameterHandler = mappedStatement.getLang().createParameterHandler(mappedStatement, parameterObject, boundSql); parameterHandler = (ParameterHandler) interceptorChain.pluginAll(parameterHandler); return parameterHandler; }
public ResultSetHandler newResultSetHandler(Executor executor, MappedStatement mappedStatement, RowBounds rowBounds, ParameterHandler parameterHandler, ResultHandler resultHandler, BoundSql boundSql) { ResultSetHandler resultSetHandler = new DefaultResultSetHandler(executor, mappedStatement, parameterHandler, resultHandler, boundSql, rowBounds); resultSetHandler = (ResultSetHandler) interceptorChain.pluginAll(resultSetHandler); return resultSetHandler; }
而具體要攔截哪些對象和哪些方法則是由@Intercepts和@Signature指定的。
以上就是Mybatis擴展插件的實現機制,讀者可據此自行分析下PageHelper的實現原理。另外須要注意,咱們在進行自定義插件開發時,尤爲要謹慎。由於直接關係到操做數據庫,若是對插件的實現原理不透徹,頗有可能引起難以估量的後果。
前面的示例都是單獨使用Mybatis,能夠看到須要建立SqlSessionFactory和SqlSession對象,而後經過SqlSession去建立Mapper接口的代理對象,因此在與Spring整合時,顯而易見的,咱們就須要考慮如下幾點:
那麼如何實現以上幾點呢?下文基於mybatis-spring-1.3.3版本分析。
熟悉Spring源碼的(若是不熟悉,能夠閱讀我以前的Spring系列源碼)都知道Spring最重要的那些擴展點:
其它還有不少,以上列舉出來的就是Mybatis集成Spring所用到的擴展點。首先咱們須要實例化SqlSessionFactory,而實例化該對象在Mybatis裏實際上就是去解析一大堆配置並封裝到該對象中,因此咱們不能簡單的使用<bean>標籤來配置,爲此Mybatis實現了一個類SqlSessionFactoryBean(這個類咱們在之前使用整合包時都會配置),以前XML中的配置都以屬性的方式放入到了該類中:
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource" /> <property name="typeAliasesPackage" value="com.enjoylearning.mybatis.entity" /> <property name="mapperLocations" value="classpath:sqlmapper/*.xml" /> </bean>
進入這個類,咱們能夠看到它實現了InitializingBean和FactoryBean接口,實現第一個接口的做用就是在該類實例化後當即去執行配置解析的階段:
public void afterPropertiesSet() throws Exception { notNull(dataSource, "Property 'dataSource' is required"); notNull(sqlSessionFactoryBuilder, "Property 'sqlSessionFactoryBuilder' is required"); state((configuration == null && configLocation == null) || !(configuration != null && configLocation != null), "Property 'configuration' and 'configLocation' can not specified with together"); this.sqlSessionFactory = buildSqlSessionFactory(); }
具體的解析就在buildSqlSessionFactory方法中,這個方法比較長,但不復雜,這裏就不貼代碼了。而實現第二接口的做用就在於Spring獲取該類實例時實際上會經過getObject方法返回SqlSessionFactory的實例,經過這兩個接口就完成了SqlSessionFactory的實例化。
在整合以後咱們除了要配置SqlSessionFactoryBean外,還要配置一個類:
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.enjoylearning.mybatis.mapper" /> </bean>
這個類的做用就是用來掃描Mapper接口的,而且這個類實現了BeanDefinitionRegistryPostProcessor和InitializingBean,這裏實現第二個接口的做用主要是校驗有沒有配置待掃描包的路徑:
public void afterPropertiesSet() throws Exception { notNull(this.basePackage, "Property 'basePackage' is required"); }
主要看到postProcessBeanDefinitionRegistry方法:
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) { if (this.processPropertyPlaceHolders) { processPropertyPlaceHolders(); } ClassPathMapperScanner scanner = new ClassPathMapperScanner(registry); scanner.setAddToConfig(this.addToConfig); scanner.setAnnotationClass(this.annotationClass); scanner.setMarkerInterface(this.markerInterface); scanner.setSqlSessionFactory(this.sqlSessionFactory); scanner.setSqlSessionTemplate(this.sqlSessionTemplate); scanner.setSqlSessionFactoryBeanName(this.sqlSessionFactoryBeanName); scanner.setSqlSessionTemplateBeanName(this.sqlSessionTemplateBeanName); scanner.setResourceLoader(this.applicationContext); scanner.setBeanNameGenerator(this.nameGenerator); scanner.registerFilters(); scanner.scan(StringUtils.tokenizeToStringArray(this.basePackage, ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS)); }
這裏建立了一個掃描類,而這個掃描類是繼承自Spring的ClassPathBeanDefinitionScanner,也就是會將掃描到的類封裝爲BeanDefinition註冊到IOC容器中去:
public int scan(String... basePackages) { int beanCountAtScanStart = this.registry.getBeanDefinitionCount(); doScan(basePackages); // Register annotation config processors, if necessary. if (this.includeAnnotationConfig) { AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry); } return (this.registry.getBeanDefinitionCount() - beanCountAtScanStart); } public Set<BeanDefinitionHolder> doScan(String... basePackages) { Set<BeanDefinitionHolder> beanDefinitions = super.doScan(basePackages); if (beanDefinitions.isEmpty()) { logger.warn("No MyBatis mapper was found in '" + Arrays.toString(basePackages) + "' package. Please check your configuration."); } else { processBeanDefinitions(beanDefinitions); } return beanDefinitions; } private void processBeanDefinitions(Set<BeanDefinitionHolder> beanDefinitions) { GenericBeanDefinition definition; for (BeanDefinitionHolder holder : beanDefinitions) { definition = (GenericBeanDefinition) holder.getBeanDefinition(); if (logger.isDebugEnabled()) { logger.debug("Creating MapperFactoryBean with name '" + holder.getBeanName() + "' and '" + definition.getBeanClassName() + "' mapperInterface"); } // the mapper interface is the original class of the bean // but, the actual class of the bean is MapperFactoryBean definition.getConstructorArgumentValues().addGenericArgumentValue(definition.getBeanClassName()); // issue #59 definition.setBeanClass(this.mapperFactoryBean.getClass()); definition.getPropertyValues().add("addToConfig", this.addToConfig); boolean explicitFactoryUsed = false; if (StringUtils.hasText(this.sqlSessionFactoryBeanName)) { definition.getPropertyValues().add("sqlSessionFactory", new RuntimeBeanReference(this.sqlSessionFactoryBeanName)); explicitFactoryUsed = true; } else if (this.sqlSessionFactory != null) { definition.getPropertyValues().add("sqlSessionFactory", this.sqlSessionFactory); explicitFactoryUsed = true; } if (StringUtils.hasText(this.sqlSessionTemplateBeanName)) { if (explicitFactoryUsed) { logger.warn("Cannot use both: sqlSessionTemplate and sqlSessionFactory together. sqlSessionFactory is ignored."); } definition.getPropertyValues().add("sqlSessionTemplate", new RuntimeBeanReference(this.sqlSessionTemplateBeanName)); explicitFactoryUsed = true; } else if (this.sqlSessionTemplate != null) { if (explicitFactoryUsed) { logger.warn("Cannot use both: sqlSessionTemplate and sqlSessionFactory together. sqlSessionFactory is ignored."); } definition.getPropertyValues().add("sqlSessionTemplate", this.sqlSessionTemplate); explicitFactoryUsed = true; } if (!explicitFactoryUsed) { if (logger.isDebugEnabled()) { logger.debug("Enabling autowire by type for MapperFactoryBean with name '" + holder.getBeanName() + "'."); } definition.setAutowireMode(AbstractBeanDefinition.AUTOWIRE_BY_TYPE); } } }
你可能會好奇,在哪裏生成的代理對象?只是將Mapper接口注入到IOC有什麼用呢?其實關鍵代碼就在definition.setBeanClass(this.mapperFactoryBean.getClass()),這句代碼的做用就是將每個Mapper接口都轉爲MapperFactoryBean類型。
爲何要這麼轉呢?進入這個類你會發現它也是實現了FactoryBean接口的,因此天然而然的又是利用它來建立代理實現類對象:
public T getObject() throws Exception { return getSqlSession().getMapper(this.mapperInterface); }
Mybatis做爲一個ORM框架,它是有本身的數據源和事務控制的,而Spring一樣也會配置這兩個,那麼怎麼將它們整合到一塊兒呢?而不是在Service類調用Mapper接口時就切換了數據源和鏈接,那樣確定是不行的。
在使用Mybatis時,咱們能夠在xml中配置TransactionFactory事務工廠類,不過通常都會使用默認的JdbcTransactionFactory,而當與Spring整合後,默認的事務工廠類改成了SpringManagedTransactionFactory。回到SqlSessionFactoryBean讀取配置的方法,在該方法中有下面這樣一段代碼:
if (this.transactionFactory == null) { this.transactionFactory = new SpringManagedTransactionFactory(); } configuration.setEnvironment(new Environment(this.environment, this.transactionFactory, this.dataSource));
上面默認建立了SpringManagedTransactionFactory,同時還將咱們xml中ref屬性引用的dataSource添加到了Configuration中,這個工廠會建立下面這個事務控制對象:
public Transaction newTransaction(DataSource dataSource, TransactionIsolationLevel level, boolean autoCommit) { return new SpringManagedTransaction(dataSource); }
而這個方法是在DefaultSqlSessionFactory獲取SqlSession時會調用:
private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) { Transaction tx = null; try { final Environment environment = configuration.getEnvironment(); final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment); tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit); final Executor executor = configuration.newExecutor(tx, execType); 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(); } }
這就保證使用的是同一個數據源對象,可是怎麼保證拿到的是同一個鏈接和事務呢?關鍵就在於SpringManagedTransaction獲取鏈接是怎麼實現的:
public Connection getConnection() throws SQLException { if (this.connection == null) { openConnection(); } return this.connection; } private void openConnection() throws SQLException { this.connection = DataSourceUtils.getConnection(this.dataSource); this.autoCommit = this.connection.getAutoCommit(); this.isConnectionTransactional = DataSourceUtils.isConnectionTransactional(this.connection, this.dataSource); if (LOGGER.isDebugEnabled()) { LOGGER.debug( "JDBC Connection [" + this.connection + "] will" + (this.isConnectionTransactional ? " " : " not ") + "be managed by Spring"); } }
這裏委託給了DataSourceUtils獲取鏈接:
public static Connection getConnection(DataSource dataSource) throws CannotGetJdbcConnectionException { try { return doGetConnection(dataSource); } catch (SQLException ex) { throw new CannotGetJdbcConnectionException("Could not get JDBC Connection", ex); } } public static Connection doGetConnection(DataSource dataSource) throws SQLException { Assert.notNull(dataSource, "No DataSource specified"); ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource(dataSource); if (conHolder != null && (conHolder.hasConnection() || conHolder.isSynchronizedWithTransaction())) { conHolder.requested(); if (!conHolder.hasConnection()) { logger.debug("Fetching resumed JDBC Connection from DataSource"); conHolder.setConnection(dataSource.getConnection()); } return conHolder.getConnection(); } // Else we either got no holder or an empty thread-bound holder here. logger.debug("Fetching JDBC Connection from DataSource"); Connection con = dataSource.getConnection(); if (TransactionSynchronizationManager.isSynchronizationActive()) { logger.debug("Registering transaction synchronization for JDBC Connection"); // Use same Connection for further JDBC actions within the transaction. // Thread-bound object will get removed by synchronization at transaction completion. ConnectionHolder holderToUse = conHolder; if (holderToUse == null) { holderToUse = new ConnectionHolder(con); } else { holderToUse.setConnection(con); } holderToUse.requested(); TransactionSynchronizationManager.registerSynchronization( new ConnectionSynchronization(holderToUse, dataSource)); holderToUse.setSynchronizedWithTransaction(true); if (holderToUse != conHolder) { TransactionSynchronizationManager.bindResource(dataSource, holderToUse); } } return con; }
看到ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource(dataSource)這段代碼相信熟悉Spring源碼的已經知道了,這個我在分析Spring事務源碼時也講過,經過DataSource對象拿到當前線程綁定的ConnectionHolder,這個對象是在Spring開啓事務的時候存進去的。至此,關於Spring和Mybatis的整合原理咱們就個搞清楚了,至於和SpringBoot的整合,讀者可自行分析。最後,我再分享一個小擴展知識。
不少讀者可能不知道這個接口有什麼做用,其實很簡單,當咱們有某個類由Spring實例化比較複雜,想要本身控制它的實例化時,就能夠實現該接口。而實現該接口的類首先會被實例化並放入一級緩存,而當咱們依賴注入咱們真正想要的類時(如Mapper接口的代理類),就會從一級緩存中拿到FactoryBean實現類的實例,並判斷是否實現了FactoryBean接口,若是是就會調用getObject方法返回咱們真正想要的實例。
那若是咱們確實想要拿到的就是FactoryBean實現類的實例該怎麼辦呢?只須要在傳入的beanName前面加上「&」符號便可。
本篇分析了Mybatis如何擴展插件以及插件的實現原理,但如非必要,切忌擴展插件,若是必定要,那麼必定要很是謹慎。另外還結合Spirng的擴展點分析了Mybatis和Spring的整合原理,解決了困在我心中已久的一些疑惑,相信那也是大多數讀者的疑惑,好好領悟這部份內容很是有利於咱們本身對Spring進行擴展。