spring整合mybatis原理
//MyBatis 中最重要的核心,SqlSessionFactory ,我们要把它交给 SpringFramework 统一管理,而 MyBatis 整合 SpringFramework 的整合包中,有这么一个 FactoryBean ,借助它就可以创建出 SqlSessionFactory :
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
<property name="dataSource" ref="dataSource"/>
<!-- MyBatis全局配置文件 -->
<property name="configLocation" value="classpath:mybatis-config.xml"/>
<property name="typeAliasesPackage" value="com.linkedbear.mybatis.entity"/>
</bean>
//可以快速操作 SqlSession 的 SqlSessionTemplate
<bean id="sqlSessionTemplate" class="org.mybatis.spring.SqlSessionTemplate">
<constructor-arg index="0" ref="sqlSessionFactory"/>
</bean>
//可以扫描 Mapper 接口的 MapperScannerConfigurer :
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
<property name="basePackage" value="com.linkedbear.mybatis.mapper"/>
<!-- 注意这里只能设置sqlSessionFactoryBeanName!!! -->
<property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/>
</bean>
1.SqlSessionFactoryBean的设计
MyBatis 的配置文件路径,以及 MyBatis 的核心 Configuration
对象
public class SqlSessionFactoryBean
implements FactoryBean<SqlSessionFactory>, InitializingBean, ApplicationListener<ApplicationEvent> {
private Resource configLocation;
private Configuration configuration;
}
SqlSessionFactoryBean
实现的接口:
FactoryBean<SqlSessionFactory>
:可以通过getObject
方法构造SqlSessionFactory
InitializingBean
:有初始化逻辑(猜想会不会就是这个初始化的切入点加载了 MyBatis 的相关东西呢?)ApplicationListener<ApplicationEvent>
:监听一些事件(实际上它只监听了ContextRefreshedEvent
事件)
2.afterPropertiesSet
@Override
public void afterPropertiesSet() throws Exception {
// 判断 ......
this.sqlSessionFactory = buildSqlSessionFactory();
}
2.1处理MyBatis全局配置对象
protected SqlSessionFactory buildSqlSessionFactory() throws Exception {
final Configuration targetConfiguration;
XMLConfigBuilder xmlConfigBuilder = null;
// 事先构造过Configuration,直接处理
if (this.configuration != null) {
targetConfiguration = this.configuration;
if (targetConfiguration.getVariables() == null) {
targetConfiguration.setVariables(this.configurationProperties);
} else if (this.configurationProperties != null) {
targetConfiguration.getVariables().putAll(this.configurationProperties);
}
} else if (this.configLocation != null) {
// 传入全局配置文件路径
xmlConfigBuilder = new XMLConfigBuilder(this.configLocation.getInputStream(), null, this.configurationProperties);
targetConfiguration = xmlConfigBuilder.getConfiguration();
} else {
// 啥也没有,一切走默认
targetConfiguration = new Configuration();
Optional.ofNullable(this.configurationProperties).ifPresent(targetConfiguration::setVariables);
}
}
先准备一个 MyBatis 的全局配置对象 Configuration
,并根据是否事先注入 configuration
对象或者传入全局配置文件路径,决定是否准备 XMLConfigBuilder
。如果确实需要 XMLConfigBuilder
的处理,在下面会有调用它的 parse
方法,后面我们会看到。
2.2.2 处理内置组件
// ......
Optional.ofNullable(this.objectFactory).ifPresent(targetConfiguration::setObjectFactory);
Optional.ofNullable(this.objectWrapperFactory).ifPresent(targetConfiguration::setObjectWrapperFactory);
Optional.ofNullable(this.vfs).ifPresent(targetConfiguration::setVfsImpl);
// ......
MyBatis 整合 SpringFramework 时,有些配置是在 <bean>
中配置而没有在 MyBatis 全局配置文件中而进行的分别处理。
2.2.3 别名处理
if (hasLength(this.typeAliasesPackage)) {
scanClasses(this.typeAliasesPackage, this.typeAliasesSuperType).stream()
.filter(clazz -> !clazz.isAnonymousClass()).filter(clazz -> !clazz.isInterface())
.filter(clazz -> !clazz.isMemberClass()).forEach(targetConfiguration.getTypeAliasRegistry()::registerAlias);
}
if (!isEmpty(this.typeAliases)) {
Stream.of(this.typeAliases).forEach(typeAlias -> {
targetConfiguration.getTypeAliasRegistry().registerAlias(typeAlias);
LOGGER.debug(() -> "Registered type alias: '" + typeAlias + "'");
});
}
别名的包扫描,和某些特定类的别名设置
默认情况下,包扫描注册的别名就是类名(首字母大写),如果类上有标注 @Alias
注解,则取注解属性值。
2.2.4 处理插件、类型处理器
if (!isEmpty(this.plugins)) {
Stream.of(this.plugins).forEach(plugin -> {
targetConfiguration.addInterceptor(plugin);
LOGGER.debug(() -> "Registered plugin: '" + plugin + "'");
});
}
if (hasLength(this.typeHandlersPackage)) {
scanClasses(this.typeHandlersPackage, TypeHandler.class).stream().filter(clazz -> !clazz.isAnonymousClass())
.filter(clazz -> !clazz.isInterface()).filter(clazz -> !Modifier.isAbstract(clazz.getModifiers()))
.forEach(targetConfiguration.getTypeHandlerRegistry()::register);
}
if (!isEmpty(this.typeHandlers)) {
Stream.of(this.typeHandlers).forEach(typeHandler -> {
targetConfiguration.getTypeHandlerRegistry().register(typeHandler);
LOGGER.debug(() -> "Registered type handler: '" + typeHandler + "'");
});
}
targetConfiguration.setDefaultEnumTypeHandler(defaultEnumTypeHandler);
处理 MyBatis 插件,以及 TypeHandler
,内容也非常简单,扫一眼即可。
默认情况下最后一行的那个 defaultEnumTypeHandler
为 null ,除非我们在注册 SqlSessionFactoryBean
时注入过,否则 MyBatis 处理枚举类型时仍会使用默认的处理器
2.2.5 处理边角组件
if (!isEmpty(this.scriptingLanguageDrivers)) {
Stream.of(this.scriptingLanguageDrivers).forEach(languageDriver -> {
targetConfiguration.getLanguageRegistry().register(languageDriver);
LOGGER.debug(() -> "Registered scripting language driver: '" + languageDriver + "'");
});
}
Optional.ofNullable(this.defaultScriptingLanguageDriver)
.ifPresent(targetConfiguration::setDefaultScriptingLanguage);
if (this.databaseIdProvider != null) {// fix #64 set databaseId before parse mapper xmls
try {
targetConfiguration.setDatabaseId(this.databaseIdProvider.getDatabaseId(this.dataSource));
} catch (SQLException e) {
throw new NestedIOException("Failed getting a databaseId", e);
}
}
Optional.ofNullable(this.cache).ifPresent(targetConfiguration::addCache);
一些组件都是边角性的了,我们平时也不会主动碰它,所以直接忽略就好啦。
2.2.6 解析MyBatis全局配置文件
if (xmlConfigBuilder != null) {
try {
xmlConfigBuilder.parse();
LOGGER.debug(() -> "Parsed configuration file: '" + this.configLocation + "'");
} catch (Exception ex) {
throw new NestedIOException("Failed to parse config resource: " + this.configLocation, ex);
} finally {
ErrorContext.instance().reset();
}
}
加载全局配置文件了,由于 xmlConfigBuilder
在执行构造器时已经把全局 Configuration
注入进去了,所以这个 parse
动作完事后,配置文件的内容也就都进入 Configuration
中了。
2.2.7 处理数据源和事务工厂
targetConfiguration.setEnvironment(new Environment(this.environment,
this.transactionFactory
数据源与事务工厂,注意默认情况下 MyBatis 与 SpringFramework 整合之后底层使用的事务工厂不再是 JdbcTransactionFactory
,而是 SpringManagedTransactionFactory
,不过底层的逻辑与原生 jdbc 并无太大差别。
2.2.8 处理Mapper
if (this.mapperLocations != null) {
if (this.mapperLocations.length == 0) {
LOGGER.warn(() -> "Property 'mapperLocations' was specified but matching resources are not found.");
} else {
for (Resource mapperLocation : this.mapperLocations) {
if (mapperLocation == null) {
continue;
}
try {
XMLMapperBuilder xmlMapperBuilder = new XMLMapperBuilder(mapperLocation.getInputStream(),
targetConfiguration, mapperLocation.toString(), targetConfiguration.getSqlFragments());
xmlMapperBuilder.parse();
} catch (Exception e) {
throw new NestedIOException("Failed to parse mapping resource: '" + mapperLocation + "'", e);
} finally {
ErrorContext.instance().reset();
}
LOGGER.debug(() -> "Parsed mapper file: '" + mapperLocation + "'");
}
}
} else {
LOGGER.debug(() -> "Property 'mapperLocations' was not specified.");
}
return this.sqlSessionFactoryBuilder.build(targetConfiguration);
}
SqlSessionFactoryBean
只能传入 mapper.xml 的路径,所以这里的处理逻辑只有加载和解析 mapper.xml ,至于 Mapper 接口的话,那是另外的 MapperScannerConfigurer
了,我们马上就说它。
经过这么一大段 afterPropertiesSet
的逻辑,SqlSessionFactory
也就创建出来了。
整个 SqlSessionFactoryBean
的任务也就全部完成了,抓住几个要点即可:
- 几乎可以代替 MyBatis 全局配置文件
- 可以传入全局配置文件,供 MyBatis 解析和处理
- 代替 MyBatis 处理数据源和事务工厂
- 只处理和解析 mapper.xml
SqlSessionFactoryBean
只负责 mapper.xml 的处理,那 Mapper 接口怎么办呢?哎别急,下面还有一个组件呢。
3 MapperScannerConfigurer
3.1类的设计
public class MapperScannerConfigurer
implements BeanDefinitionRegistryPostProcessor, InitializingBean, ApplicationContextAware, BeanNameAware {}
**BeanDefinitionRegistryPostProcessor
的处理阶段最好不要直接使用 getBean
或者相似的方法去获取 IOC 容器中的 Bean **,如果只是为了检查或者依赖相关的 bean 的话,可以只依赖 bean 的 name 。
核心的处理逻辑,**BeanDefinitionRegistryPostProcessor
的核心方法是 postProcessBeanDefinitionRegistry
,这个方法会向 BeanDefinitionRegistry
中注册新的 BeanDefinition
**,具体的逻辑我们可以来看看源码逻辑:
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
if (this.processPropertyPlaceHolders) {
processPropertyPlaceHolders();
}
ClassPathMapperScanner scanner = new ClassPathMapperScanner(registry);
// 一大堆set方法
scanner.registerFilters();
scanner.scan(
StringUtils.tokenizeToStringArray(this.basePackage, ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS));
}
核心是这个 ClassPathMapperScanner
,它会执行包扫描的动作,并且将扫描到的 Mapper 接口都收集起来,构造为一个一个的 MapperFactoryBean
( MapperFactoryBean
想必各位都不会觉得陌生吧,它就是适配 Mapper 接口的工厂 Bean )。那么核心的逻辑也就是 ClassPathMapperScanner
的 scan 方法了。
3.2 scan
很不巧,这个 scan
方法其实是 ClassPathBeanDefinitionScanner
的,因为 ClassPathMapperScanner
继承自 ClassPathBeanDefinitionScanner
,所以会先来到 ClassPathBeanDefinitionScanner
中:
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);
}
SpringFramework 的经典套路了,xxx 方法最终调用 doXxx 方法,真正负责干活的是 doXxx 方法。**doXxx 方法应该是类似于模板方法那样,让子类重写了
3.3doScan
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;
}
ClassPathMapperScanner
重写了 doScan
方法,也仅仅是多了一层 BeanDefinition
的处理而已,包扫描的逻辑还是用的 ClassPathBeanDefinitionScanner
的,主要是看扫描到 Mapper 接口之后都干了什么。
3.4 processBeanDefinitions
private void processBeanDefinitions(Set<BeanDefinitionHolder> beanDefinitions) {
GenericBeanDefinition definition;
for (BeanDefinitionHolder holder : beanDefinitions) {
definition = (GenericBeanDefinition) holder.getBeanDefinition();
// 获取Mapper接口的全限定名
String beanClassName = definition.getBeanClassName();
// logger ......
// the mapper interface is the original class of the bean
// but, the actual class of the bean is MapperFactoryBean
// MapperFactoryBean的构造方法需要传入Mapper接口名
definition.getConstructorArgumentValues().addGenericArgumentValue(beanClassName); // issue #59
definition.setBeanClass(this.mapperFactoryBeanClass);
definition.getPropertyValues().add("addToConfig", this.addToConfig);
// 给MapperFactoryBean传入SqlSessionFactory
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;
}
// 同样的逻辑处理SqlSessionTemplate ......
if (!explicitFactoryUsed) {
LOGGER.debug(() -> "Enabling autowire by type for MapperFactoryBean with name '" + holder.getBeanName() + "'.");
definition.setAutowireMode(AbstractBeanDefinition.AUTOWIRE_BY_TYPE);
}
definition.setLazyInit(lazyInitialization);
}
}
大体走下来,就这么两大步骤:拿着 Mapper 接口的全限定名创建 MapperFactoryBean
,注入 SqlSessionFactory
和 SqlSessionTemplate
。
处理好这些 BeanDefinition
之后,其实 BeanDefinitionRegistry
中就有这些 MapperFactoryBean
的定义了,后续的 bean 实例化阶段也就都能创建出对应的代理对象了,程序执行阶段也就可以拿得到了。