操作数据一般都是在DAO层进行处理，

1、可以选择直接使用JDBC进行编程
2、使用多个DataSource 然后创建多个SessionFactory，在使用Dao层的时候通过不同的SessionFactory进行处理，不过这样的入侵性比较明显，一般的情况下我们都是使用继承HibernateSupportDao进行封装了的处理，如果多个SessionFactory这样处理就是比较的麻烦了，修改的地方估计也是蛮多的
3、使用AbstractRoutingDataSource的实现类通过AOP或者手动处理实现动态的使用我们的数据源，这样的入侵性较低，非常好的满足使用的需求。比如我们希望对于读写分离或者其他的数据同步的业务场景

 

 

 

 

单数据源的场景（一般的Web项目工程这样配置进行处理，就已经比较能够满足我们的业务需求）
多数据源多SessionFactory这样的场景，估计作为刚刚开始想象想处理在使用框架的情况下处理业务，配置多个SessionFactory，然后在Dao层中对于特定的请求，通过特定的SessionFactory即可处理实现这样的业务需求，不过这样的处理带来了很多的不便之处，所有很多情况下我们宁愿直接使用封装的JDBC编程，或者使用Mybatis处理这样的业务场景

●使用AbstractRoutingDataSource 的实现类，进行灵活的切换，可以通过AOP或者手动编程设置当前的DataSource，不用修改我们编写的对于继承HibernateSupportDao的实现类的修改，这样的编写方式比较好，至于其中的实现原理，让我细细到来。我们想看看如何去应用，实现原理慢慢的说！

●编写AbstractRoutingDataSource的实现类,HandlerDataSource就是提供给我们动态选择数据源的数据的信息，我们这里编写一个根据当前线程来选择数据源，然后通过AOP拦截特定的注解，设置当前的数据源信息，也可以手动的设置当前的数据源，在编程的类中。

 

 

 

Spring2.x的版本中采用Proxy模式，就是我们在方案中实现一个虚拟的数据源，并且用它来封装数据源选择逻辑，这样就可以有效地将数据源选择逻辑从Client中分离出来。Client提供选择所需的上下文（因为这是Client所知道的），由虚拟的DataSource根据Client提供的上下文来实现数据源的选择。 
具体的实现就是，虚拟的DataSource仅需继承AbstractRoutingDataSource实现determineCurrentLookupKey（）在其中封装数据源的选择逻辑

一、原理

首先看下AbstractRoutingDataSource类结构，继承了AbstractDataSource：

 

 

 

既然是AbstractDataSource，当然就是javax.sql.DataSource的子类，于是我们自然地回去看它的getConnection方法：

原来关键就在determineTargetDataSource()里：

 

这里用到了我们需要进行实现的抽象方法determineCurrentLookupKey()，该方法返回需要使用的DataSource的key值，然后根据这个key从resolvedDataSources这个map里取出对应的DataSource，如果找不到，则用默认的resolvedDefaultDataSource。

 

所以我们需要继承AbstractRoutingDataSource实现determineCurrentLookupKey方法来决定使用哪个数据连接池。

 

 

具体详细步骤可参考

spring-boot整合mybatis和druid连接池（动态数据源——读写分离）

参考：https://blog.csdn.net/qq_27840695/article/details/83543968