mybatis集成到spring可以参考spring mvc集成mybatis进行数据库访问 ，其中mybatis集成到spring最重要的两个配置分别是SqlSessionFactoryBean和MapperScannerConfigurer，如下所示：
<!--mybatis sqlSeesionFactory配置-->
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="configLocation" value="classpath:mybatis-config.xml" />
<property name="mapperLocations" value="classpath:mapper/*Mapper.xml" />
<property name="typeAliasesPackage" value="com.gameloft9.demo.dataaccess.model" />
</bean>
<!--mapper自动扫描配置-->
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
<property name="basePackage" value="com.gameloft9.demo.dataaccess.dao" />
<!-- 这里不要定义sqlSessionFactory, 定义了会导致properties文件无法加载 -->
</bean>
在之前的文章mybatis是如何集成到spring的之SqlSessionFactoryBean 中我们已经对SqlSessionFactoryBean有了初步的探讨，接下来我们继续追问mapper接口是如何被spring管理起来的。
我们平时使用mapper进行数据库操作时十分简单，首先定义好Dao层的接口：
**
* 用户Mapper
* Created by gameloft9 on 2017/11/28.
*/
public interface UserMapper {
/**
* 根据主键查询用户信息
*/
UserTest selectByPrimaryKey(String id);
}
然后在repository层通过@Autowire就可以自动注入并使用了：
多么神奇的魔法！但我们需要对其一探究竟。我们先根据现有的知识提出几个问题，然后带着问题找答案：
1、我并没有定义任何UserMapper的Bean，它是怎么自动创建的？
MapperScannerConfigurer是专门用来扫描mapper接口并创建对应的spring bean。它的结构如下所示：
MapperScannerConfigurer实现了两个非常重要的接口BeanDefinitionRegistryPostProcessor和InitializingBean，其中InitializingBean我们已经很熟悉了。BeanDefinitionRegistryPostProcessor用的人比较少：
BeanDefinitionRegistryPostProcessor可以在bean被初始化前，让你修改applicationContext内部的BeanDefinition，加一些你想要的东西。
由此可见，MapperScannerConfigurer里面对某些BeanDefinition动了手脚，我们进去看看它做了什么：
看来MapperScannerConfigurer比较懒，它把工作丢给了ClassPathMapperScanner来做了。由于我们只配置了basePackage，所以被叉掉的部分不用去管它，重点是这个scan方法（basePackage可以是用分隔符分割的包，这里做了简单的分割。）在看scan方法前，我们先简单整理下流程：
MapperScannerConfigurer主要是读取需要扫描mapper的包路径，然后对其做一个简单的检查，然后提供一个可以对BeanDefinition做修改的入口，具体的修改工作交给了ClassPathMapperScanner。
好像ClassPathMapperScanner才是真正做苦力的那位老实人，在spring扫描完我们提供的包路径并创建完BeanDefinition后，ClassPathMapperScanner开始对BeanDefinition进行魔改。其中最重要的两点就是把mapper的className传给了构造函数以及篡改了bean的class为MapperFactoryBean。
在修改完Bean定义后，根据spring Bean的生命周期，肯定会创建Bean的实例。我们再看看修改这两个东西有什么用？
MapperFactoryBean的类结构如下：
实际上看到FactoryBean基本就可以断定mapper的代理bean是通过getObject创建的，实际上也确实如此：
对FactoryBean不熟悉的同学这里再简单提一下：
Spring 中有两种类型的Bean，一种是普通Bean，另一种是工厂Bean 即 FactoryBean。FactoryBean跟普通Bean不同，其返回的对象不是指定类的一个实例，而是该FactoryBean的getObject方法所返回的对象。
一般情况下，Spring通过反射机制利用的class属性指定实现类实例化Bean，在某些情况下，实例化Bean过程比较复杂，Spring为此提供了一个org.springframework.bean.factory.FactoryBean的工厂类接口，用户可以通过实现该接口定制实例化Bean的逻辑。
看到getSqlSession().getMapper(this.mapperInterface)是不是很熟悉了？后面就正式进去到mybatis内部创建mapper代理对象的流程里去了，spring和mybatis的连接就建立起来了！
现在可以回答刚才的问题了，BeanDefinition修改了BeanClass为MapperFactoryBean.class，那么创建的时候是MapperFactoryBean的实例，然后因为添加了构造函数入参为原始的接口，所以原始的mapper的class也一并传递了进去，这样mapperFactoryBean的mapperInterface字段就保存着原始的mapper接口名称。
又由于MapperFactoryBean实现了FactoryBean接口，所以获取mapper实例的时候，实际调用的是getObject方法，把真正要创建的mapper接口传给getMapper方法，这样原始的mapper的代理对象就可以通过mybatis创建了。
MapperFactoryBean继承了SqlSessionDaoSupport实际上有好几个作用：
1、最重要的，是可以获取SqlSession对象，这样才可以创建mapper的代理对象
2、做一些简单的检查，例如mapperInterface不能为空
mapper bean的动态创建，通过扫描包并修改BeanDefinition，然后自定义的复杂的初始化逻辑通过实现InitializingBean+FactoryBean接口来达到目的。
作者曾经做过一个支付项目，支付渠道系统开放出来的远程dubbo服务就一个：
/**
* 微信渠道服务
*/
public interface WxDubboService {
// 服务调用，所有服务都走它，包括下单，查询，退款等操作
// jsonStr里面有具体的操作的msgType，根据它组装不通过服务处理链路
String invoke(String jsonStr);
}
内部具体业务怎么处理全部通过一个msgType来区分，具体的业务服务配置大概长这个样子：
<bean id="refundService" class="com.xx.xx.xx.BusinessService">
<property name="msgType">
<util:constant static-field="com.xx.xx.wx.config.WXConstant$MsgType.REFUND" />
</property>
<property name="targetSys">
<util:constant static-field="com.xx.xx.framework.config.Constant$TargetSys.WX" />
</property>
<property name="name" value="微信交易退款" />
<property name="requestClass">
<bean class="com.xx.xx.wx.jsonbean.RefundRequest" />
</property>
<property name="filterTemplate" ref="refundFilterTemplate" />
<property name="businessHandler" ref="refundServiceHandler" />
</bean>
然后服务的调用实现实际上是根据不同的msgType，然后通过注册中心拿到具体的BusinessService进行处理。这样的好处显而易见，内部子系统调用接口不需要新增，只需要新增msgType和对应的BusinessService即可，减少了接口数量。坏处也很明显，内部调用的逻辑复杂，必须知道msgType才知道最后走的是哪个调用。排查问题和理解难度都比普通dubbo服务要高。从本篇文章我们能有什么启发呢？
通过对比，我们可以大致看到和mybatis的逻辑是类似的，底层通过统一的服务来处理所有的逻辑，然后需要对外支持不同的接口。因此，我们可以类似的创建不同接口的Bean，然后通过FactoryBean将其实现丢给原来统一过的调用逻辑。
首先类似MapperScannerConfigurer我们配置一个ServiceScannerConfigurer：
<!--service自动扫描配置-->
<bean class="com.gameloft9.demo.mgrframework.mapper.ServiceScannerConfigurer">
<property name="basePackage" value="com.gameloft9.demo.service.api.out" />
</bean>
basePackage就是我们要提供的服务所在的package，我们在out package里面写一个测试接口：
/**
* 微信订单服务
*/
public interface WxRefundService {
// 退款
String refund(String json);
}
剩下的就是一样的套路，我们在ServiceScannerConfigurer篡改BeanDefinition：
public class ServiceScannerConfigurer implements BeanDefinitionRegistryPostProcessor, InitializingBean {
// api包
private String basePackage;
public void afterPropertiesSet() throws Exception {
notNull(this.basePackage, "Property 'basePackage' is required");
}
// 扫描api包，并篡改BeanDefitnition
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException {
ClassPathServiceScanner scanner = new ClassPathServiceScanner(registry);
scanner.registerFilters();
scanner.scan(StringUtils.tokenizeToStringArray(this.basePackage, ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS));
}
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
}
public String getBasePackage() {
return basePackage;
}
public void setBasePackage(String basePackage) {
this.basePackage = basePackage;
}
public class ClassPathServiceScanner extends ClassPathBeanDefinitionScanner {
// Service工厂Bean
private ServiceFactoryBean<?> serviceFactoryBean = new ServiceFactoryBean<Object>();
public ClassPathServiceScanner(BeanDefinitionRegistry registry) {
super(registry);
}
@Override
public Set<BeanDefinitionHolder> doScan(String... basePackages) {
Set<BeanDefinitionHolder> beanDefinitions = super.doScan(basePackages);
if (beanDefinitions.isEmpty()) {
logger.warn("No service was found in '" + Arrays.toString(basePackages) + "' package. Please check your configuration.");
} else {
processBeanDefinitions(beanDefinitions);
}
return beanDefinitions;
}
// 篡改BeanDefinition
private void processBeanDefinitions(Set<BeanDefinitionHolder> beanDefinitions) {
GenericBeanDefinition definition;
for (BeanDefinitionHolder holder : beanDefinitions) {
definition = (GenericBeanDefinition) holder.getBeanDefinition();
// 保存原始interface
definition.getConstructorArgumentValues().addGenericArgumentValue(definition.getBeanClassName());
// 篡改BeanClass为serviceFactoryBean
definition.setBeanClass(this.serviceFactoryBean.getClass());
definition.setAutowireMode(AbstractBeanDefinition.AUTOWIRE_BY_TYPE);
}
}
// 注册过滤器
public void registerFilters() {
boolean acceptAllInterfaces = true;
// 支持接口
if (acceptAllInterfaces) {
// default include filter that accepts all classes
addIncludeFilter(new TypeFilter() {
public boolean match(MetadataReader metadataReader, MetadataReaderFactory metadataReaderFactory) throws IOException {
return true;
}
});
}
// 去掉 package-info.java
addExcludeFilter(new TypeFilter() {
public boolean match(MetadataReader metadataReader, MetadataReaderFactory metadataReaderFactory) throws IOException {
String className = metadataReader.getClassMetadata().getClassName();
return className.endsWith("package-info");
}
});
}
// 保证接口可以注册BeanDefinition
@Override
protected boolean isCandidateComponent(AnnotatedBeanDefinition beanDefinition) {
return beanDefinition.getMetadata().isInterface() && beanDefinition.getMetadata().isIndependent();
}
/**
* {@inheritDoc}
*/
@Override
protected boolean checkCandidate(String beanName, BeanDefinition beanDefinition) {
if (super.checkCandidate(beanName, beanDefinition)) {
return true;
} else {
logger.warn("Skipping ServiceFactoryBean with name '" + beanName
+ "' and '" + beanDefinition.getBeanClassName() + "' serviceInterface"
+ ". Bean already defined with the same name!");
return false;
}
}
public ServiceFactoryBean<?> getServiceFactoryBean() {
return serviceFactoryBean;
}
public void setServiceFactoryBean(ServiceFactoryBean<?> serviceFactoryBean) {
this.serviceFactoryBean = serviceFactoryBean;
}
}
然后在ServiceFactoryBean中创建代理类：
public class ServiceFactoryBean<T> implements FactoryBean<T>, ApplicationContextAware {
/**
* 要代理的接口类
*/
private Class<T> serviceInterface;
// 可以通过context获取其他spring bean
private ApplicationContext context;
public ServiceFactoryBean() {
}
public ServiceFactoryBean(Class<T> serviceInterface) {
this.serviceInterface = serviceInterface;
}
// 创建代理对象
public T getObject() throws Exception {
// 内部服务注册中心
ServiceRegister serviceRegister = (ServiceRegister ) context.getBean("serviceRegister");
// 不管是直接走动态代理还是调用其他处理逻辑，背后一定少不了动态代理的东西
return (T)newProxyInstance(
ServiceFactoryBean.class.getClassLoader(),
new Class[] { serviceInterface },
new ServiceInterceptor(serviceRegister));
}
public Class<?> getObjectType() {
return this.serviceInterface;
}
public boolean isSingleton() {
return true;
}
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
context = applicationContext;
}
// 代理
private class ServiceInterceptor implements InvocationHandler{
private ServiceRegister serviceRegister;
public ServiceInterceptor(ServiceRegister serviceRegister){
this.serviceRegister= serviceRegister;
}
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
// 请求参数
JsonObject json = JSON.pareObject(args[0]);
// 真正的服务处理
BusinessService service = serviceRegister.get(json.get("msgType"));
return service.invoke(args[0]);
}
}
public Class<T> getServiceInterface() {
return serviceInterface;
}
public void setServiceInterface(Class<T> serviceInterface) {
this.serviceInterface = serviceInterface;
}
}
ServiceRegister 可以理解为一个HashMap，里面根据msgType注册了具体的业务处理类。我们来写一个测试类：
@Slf4j
@ActiveProfiles("local")
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "classpath:/applicationContext.xml")
public class WxRefundServiceTest {
// 自动注入
@Autowired
WxRefundService wxRefundService;
@Test
public void test(){
OrderEntity orderEntity = new OrderEntity();
orderEntity.setMerOrderId("xxxx");
orderEntity.setAmount(1L);
orderEntity.setMemo("付款备注");
JSONObject jsonObject = new JSONObject();
jsonObject.put("msgType","refund");
jsonObject.put("order",orderEntity);
String result = wxRefundService.refund(jsonObject.toString());
log.info("{}",result);
}
}
可以看到我们只是写了一个接口，却可以通过@Autuwired把bean给注入成功，而且调用wxRefundService.refund比调用wxDubboService .invoke更容易理解了。（这里省略了dubbo服务的发布改造）
mybatis集成到spring最重要的两个配置分别是SqlSessionFactoryBean和MapperScannerConfigurer，其中MapperScannerConfigurer帮助我们把mapper对象托管到spring。使得我们没有定义任何Mapper的Bean，却可以通过@Autowired进行注入，大大简化了我们开发的难度，让我们把重心放在了sql逻辑本身。
这是一种非常好的设计思路，当我们日常工作中想把类托管到spring但又无法定义Bean或者不好定义Bean的时候，可以采取这种解决方案。