摘要: 本文结合《Spring源码深度解析》来分析Spring 5.0.6版本的源代码。若有描述错误之处，欢迎指正。
目录
一、MapperFactoryBean的初始化
二、获取 MapperFactoryBean 的实例
为了使用MyBatis功能，示例中的Spring配置文件提供了两个bean，除了之前分析的 SqlSessionFactoryBean 类型的 bean 以外，还有一个是 MapperFactoryBean 类型的 bean。
结合两个测试用例综合分析，对于单独使用MyBatis的时候调用数据库接口的方式是：
UserMapper userMapper = sqlSession.getMapper(UserMapper.class);
而在这一过程中，其实是MyBatis在获取映射的过程中根据配置信息为UserMapper类型动态创建了代理类。而对于Spring的创建方式：
UserMapper userMapper = (UserMapper) context.getBean("userMapper");
Spring中获取的名为userMapper的bean，其实是与单独使用MyBatis完成了—样的功能，那么我们可以推断，在bean的创建过程中一定是使用了MyBatis中的原生方法sqlSession.getMapper(UserMapper.class)进行了再一次封装。结合配置文件，我们把分析目标转向org.mybatis.spring.mapper.MapperFactoryBean，初步推测其中的逻辑应该在此类中实现。同样，还是首先查看的类层次结构图MapperFactoryBean，如下图所示。
同样，在实现的接口中发现了我们感兴趣的两个接口InitializingBean与FactoryBean。我们的分析还是从bean的初始化开始。
一、MapperFactoryBean的初始化
因为实现了InitializingBean接口，Spring会保证在bean初始化时首先调用afterPropertiesSet方法来完成其初始化逻辑。追踪父类，发现afterPropertiesSet方法是在DaoSupport类中实现，代码如下：
@Override
public final void afterPropertiesSet() throws IllegalArgumentException, BeanInitializationException {
// Let abstract subclasses check their configuration.
checkDaoConfig(); // Let concrete implementations initialize themselves.
try {
initDao();
}
catch (Exception ex) {
throw new BeanInitializationException("Initialization of DAO failed", ex);
}
}
但从函数名称来看我们大体推测，MapperFactoryBean的初始化包括对DAO配置的验证以及对DAO的初始工作，其中initDao()方法是模板方法，设计为留给子类做进一步逻辑处理。而checkDaoConfig()才是我们分析的重点。
@Override
protected void checkDaoConfig() {
super.checkDaoConfig(); notNull(this.mapperInterface, "Property 'mapperInterface' is required"); Configuration configuration = getSqlSession().getConfiguration();
if (this.addToConfig && !configuration.hasMapper(this.mapperInterface)) {
try {
configuration.addMapper(this.mapperInterface);
} catch (Exception e) {
logger.error("Error while adding the mapper '" + this.mapperInterface + "' to configuration.", e);
throw new IllegalArgumentException(e);
} finally {
ErrorContext.instance().reset();
}
}
}
super.checkDaoConfig()在SqlSessionDaoSupport类中实现，代码如下：
@Override
protected void checkDaoConfig() {
notNull(this.sqlSessionTemplate, "Property 'sqlSessionFactory' or 'sqlSessionTemplate' are required");
}
结合代码我们了解到对于DAO配置的验证，Spring做了以下几个方面的工作。
- 父类中对于sqlSession不为空的验证。
sqlSession作为根据接口创建映射器代理的接触类一定不可以为空，而sqlSession的初始化工作是在设定其sqlSessionFactory属性时完成的。
public void setSqlSessionFactory(SqlSessionFactory sqlSessionFactory) {
if (this.sqlSessionTemplate == null || sqlSessionFactory != this.sqlSessionTemplate.getSqlSessionFactory()) {
this.sqlSessionTemplate = createSqlSessionTemplate(sqlSessionFactory);
}
}
也就是说，对于下面的配置如果忽略了对于sqlSessionFactoiy属性的设置，那么在此时就会被检测出来。
<bean id="userMapper" class="org.mybatis.spring.mapper.MapperFactoryBean">
<property name="mapperInterface" value="org.cellphone.uc.repo.mapper.UserMapper"/>
<property name="sqlSessionFactory" ref="sqlSessionFactory"/>
</bean>
- 映射接口的验证。
接口是映射器的基础，sqlSession会根据接口动态创建相应的代理类，所以接口必不可少。
- 映射文件存在性验证。
对于函数前半部分的验证我们都很容易理解，无非是对配置文件中的属性是否存在做验证，但是后面部分是完成了什么方面的验证呢？如果读者读过MyBatis源码，你就会知道，在MyBatis实现过程中并没有手动调用configuration.addMapper方法，而是在映射文件读取过程中一旦解析到如<mapper namespace="org.cellphone.uc.repo.mapper.UserMapper">，便会自动进行类型映射的注册。那么，Spring中为什么会把这个功能单独拿出来放在验证里呢？这是不是多此一举呢？
在上面的函数中，configuration.addMapper(this.mapperInterface)其实就是将 UserMapper 注册到映射类型中，如果你可以保证这个接口一定存在对应的映射文件，那么其实这个验证并没有必要。但是，由于这个是我们自行决定的配置，无法保证这里配罝的接口一定存在对应的映射文件，所以这里非常有必要进行验证。在执行此代码的时候，MyBatis会检査嵌人的映射接口是否存在对应的映射文件，如果没有回抛出异常，Spring正是在用这种方式来完成接口对应的映射文件存在性验证。
二、获取 MapperFactoryBean 的实例
由于MapperFactoryBean实现了FactoryBean接口，所以当通过getBean方法获取对应实例的时候其实是获取该类的getObject()函数返回的实例。
@Override
public T getObject() throws Exception {
return getSqlSession().getMapper(this.mapperInterface);
}
这段代码正是我们在提供MyBatis独立使用的时候的一个代码调用。Spring通过 FactoryBean 进行了封装。