在我们的项目中遇到这样一个问题：我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。我们以往在 spring 和 hibernate 框架中总是配置一个数据源，因而 sessionFactory 的 dataSource 属性总是指向这个数据源并且恒定不变，所有 DAO 在使用 sessionFactory 的时候都是通过这个数据源访问数据库。但是现在，由于项目的需要，我们的 DAO 在访问 sessionFactory 的时候都不得不在多个数据源中不断切换，问题就出现了：如何让 sessionFactory 在执行数据持久化的时候，根据客户的需求能够动态切换不同的数据源？我们能不能在 spring 的框架下通过少量修改得到解决？是否有什么设计模式可以利用呢？
我首先想到在 spring 的 applicationContext 中配置所有的 dataSource 。这些 dataSource 可能是各种不同类型的，比如不同的数据库： Oracle 、 SQL Server 、 MySQL 等，也可能是不同的数据源：比如 apache 提供的 org.apache.commons.dbcp.BasicDataSource 、 spring 提供的 org.springframework.jndi.JndiObjectFactoryBean 等。然后 sessionFactory 根据客户的每次请求，将 dataSource 属性设置成不同的数据源，以到达切换数据源的目的。
但是，我很快发现一个问题：当多用户同时并发访问数据库的时候会出现资源争用的问题。这都是“单例模式”惹的祸。众所周知，我们在使用 spring 框架的时候，在 beanFactory 中注册的 bean 基本上都是采用单例模式，即 spring 在启动的时候，这些 bean 就装载到内存中，并且每个 bean 在整个项目中只存在一个对象。正因为只存在一个对象，对象的所有属性，更准确说是实例变量，表现得就如同是个静态变量（实际上“静态”与“单例”往往是非常相似的两个东西，我们常常用“静态”来实现“单例”）。拿我们的问题来说， sessionFactory 在整个项目中只有一个对象，它的实例变量 dataSource 也就只有一个，就如同一个静态变量一般。如果不同的用户都不断地去修改 dataSource 的值，必然会出现多用户争用一个变量的问题，对系统产生隐患。
通过以上的分析，解决多数据源访问问题的关键，就集中在 sessionFactory 在执行数据持久化的时候，能够通过某段代码去根据客户的需要动态切换数据源，并解决资源争用的问题。
要解决这个问题，我的思路锁定在了这个 dataSource 上了。如果 sessionFactory 指向的 dataSource 可以根据客户的需求去连接客户所需要的真正的数据源，即提供动态切换数据源的功能，那么问题就解决了。那么我们怎么做呢？去修改那些我们要使用的 dataSource 源码吗？这显然不是一个好的方案，我们希望我们的修改与原 dataSource 代码是分离的。根据以上的分析，使用 GoF 设计模式中的 Decorator 模式（装饰者模式）应当是我们可以选择的最佳方案。
什么是“ Decorator 模式”？简单点儿说就是当我们需要修改原有的功能，但我们又不愿直接去修改原有的代码时，设计一个 Decorator 套在原有代码外面。当我们使用 Decorator 的时候与原类完全一样，当 Decorator 的某些功能却已经修改为了我们需要修改的功能。 Decorator 模式的结构如图。
我们本来需要修改图中所有具体的 Component 类的一些功能，但却并不是去直接修改它们的代码，而是在它们的外面增加一个 Decorator 。 Decorator 与具体的 Component 类都是继承的 AbstractComponent ，因此它长得和具体的 Component 类一样，也就是说我们在使用 Decorator 的时候就如同在使用 ConcreteComponentA 或者 ConcreteComponentB 一样，甚至那些使用 ConcreteComponentA 或者 ConcreteComponentB 的客户程序都不知道它们用的类已经改为了 Decorator ，但是 Decorator 已经对具体的 Component 类的部分方法进行了修改，执行这些方法的结果已经不同了。
现在回到我们的问题，我们需要对 dataSource 的功能进行变更，但又不希望修改 dataSource 中的任何代码。我这里指的 dataSource 是所有实现 javax.sql.DataSource 接口的类，我们常用的包括 apache 提供的 org.apache.commons.dbcp.BasicDataSource 、 spring 提供的 org.springframework.jndi.JndiObjectFactoryBean 等，这些类我们不可能修改它们本身，更不可能对它们一个个地修改以实现动态分配数据源的功能，同时，我们又希望使用 dataSource 的 sessionFactory 根本就感觉不到这样的变化。 Decorator 模式就正是解决这个问题的设计模式。
首先写一个 Decorator 类，我取名叫 MultiDataSource，通过它来动态切换数据源 。同时在配置文件中将sessionFactory的dataSource属性由原来的某个具体的dataSource改为MultiDataSource。如图：
对比原Decorator 模式， AbstractComponent 是一个抽象类，但在这里我们可以将这个抽象类用接口来代替，即 DataSource 接口，而 ConcreteComponent 就是那些 DataSource 的实现类，如 BasicDataSource 、 JndiObjectFactoryBean 等。 MultiDataSource 封装了具体的dataSource，并实现了数据源动态切换：
客户在发出请求的时候，将dataSourceName放到request中，然后把request中的数据源名通过调用new MultiDataSource(dataSource) 时可以告诉 MultiDataSource 客户需要的数据源，就可以实现动态切换数据源了。但细心的朋友会发现这在单例的情况下就是问题的，因为 MultiDataSource 在系统中只有一个对象，它的实例变量 dataSource 也只有一个，就如同一个静态变量一般。正因为如此， 单例模式让许多设计模式都不得不需要更改，这将在我的《“单例”更改了我们的设计模式》中详细讨论。那么，我们在单例模式下如何设计呢？
在单例模式下，由于我们在每次调用 MultiDataSource 的方法的时候， dataSource 都可能是不同的，所以我们不能将 dataSource 放在实例变量 dataSource 中，最简单的方式就是在方法 getDataSource() 中增加参数，告诉 MultiDataSource 我到底调用的是哪个 dataSource ：
值得一提的是，我需要的数据源已经都在spring 的配置文件中注册， dataSourceName 就是其对应的 id 。
为了得到spring 的 ApplicationContext ， MultiDataSource 类必须实现接口 org.springframework.context.ApplicationContextAware ，并且实现方法：
如此这样，我就可以通过this . applicationContext .getBean(dataSourceName) 得到 dataSource 了。
查看以上设计， MultiDataSource 依然无法运行，因为用户在发出请求时，他需要连接什么数据库，其数据源名是放在 request 中的，要将 request 中的数据源名传给 MultiDataSource ，需要经过 BUS 和 DAO ，也就是说为了把数据源名传给 MultiDataSource ， BUS 和 DAO 的所有方法都要增加 dataSourceName 的参数，这是我们不愿看到的。写一个类，通过线程的方式跳过 BUS 和 DAO 直接传递给 MultiDataSource 是一个不错的设计：
做一个filter ，每次客户发出请求的时候就调用 SpObserver.petSp ( dataSourceName ) ，将 request 中的 dataSourceName 传递给 SpObserver 对象。 最后修改 MultiDataSource 的方法 getDataSource() ：
完整的MultiDataSource 代码在附件中。
通过以上方案，我们解决了动态分配数据源的问题，但你可能提出疑问：方案中的数据源都是配置在 spring 的 ApplicationContext 中，如果我在程序运行过程中动态添加数据源怎么办？这确实是一个问题，而且在我们的项目中也确实遇到。 spring 的 ApplicationContext 是在项目启动的时候加载的。加载以后，我们如何动态地加载新的 bean 到 ApplicationContext 中呢？我想到如果用 spring 自己的方法解决这个问题就好了。所幸的是，在查看 spring 的源代码后，我找到了这样的代码，编写了 DynamicLoadBean 类，只要 调用loadBean() 方法，就可以将某个或某几个配置文件中的 bean 加载到 ApplicationContext 中（见附件）。不通过配置文件直接加载对象，在 spring 的源码中也有，感兴趣的朋友可以自己研究。
在完成了所有这些设计以后，我最后再唠叨一句。我们应当在 spring 中做如下配置：
其中dataSource 属性实际上更准确地说应当是 defaultDataSource ，即 spring 启动时以及在客户没有指定数据源时应当指定的默认数据源。
以上方案与其它方案相比，它有哪些优势呢？
首先，这个方案完全是在 spring 的框架下解决的，数据源依然配置在 spring 的配置文件中， sessionFactory 依然去配置它的 dataSource 属性，它甚至都不知道 dataSource 的改变。唯一不同的是在真正的 dataSource 与 sessionFactory 之间增加了一个 MultiDataSource 。
其次，实现简单，易于维护。这个方案虽然我说了这么多东西，其实都是分析，真正需要我们写的代码就只有 MultiDataSource 、 SpObserver 两个类。 MultiDataSource 类真正要写的只有 getDataSource() 和 getDataSource(sp) 两个方法，而 SpObserver 类更简单了。实现越简单，出错的可能就越小，维护性就越高。
最后，这个方案可以使单数据源与多数据源兼容。这个方案完全不影响 BUS 和 DAO 的编写。如果我们的项目在开始之初是单数据源的情况下开发，随着项目的进行，需要变更为多数据源，则只需要修改 spring 配置，并少量修改 MVC 层以便在请求中写入需要的数据源名，变更就完成了。如果我们的项目希望改回单数据源，则只需要简单修改配置文件。这样，为我们的项目将增加更多的弹性。
特别说明：实例中的 DynamicLoadBean在web环境下运行会出错，需要将类中AbstractApplicationContext改为 org.springframework.context.ConfigurableApplicationContext。
手机扫一扫，欢迎关注公众号
关注程序员成长
