How to create a DAO when a dynamic data source changes dynamically

Question

Typically, when defining a DAO, you should have a setter for the data source on the DAO object. My problem is that our data source is dynamically changing based on a server request. that is, each query can refer to a different instance of the database.

The query contains logical properties that can later be used to retrieve the connection to the query database.

Therefore, when a dependency injects a DAO into a business logic object, I need a way to set properties in the DAO at runtime (not configuration time).

One solution is to keep the data source in the stream local, but I don't really like messing with the local variables of the stream.

Another option is to have a business logic object initialization method that calls initialization in the DAO using query properties.

I assume this is a common problem, can you suggest a general solution?

Answer 1

It seems your problem is that you are creating a separate instance of DAO for your application. You either need to create a separate instance for each data source (maybe make some kind of dao controller to manage all this for you), or maybe let your methods in your dao be static and pass all the information about how to connect to the source data along with the data that you save in each method.

Answer 2

Your problem is a bit confusing. Having one DAO access to several different data sources seems to be a nightmare for maintenance. As a result, you must define one DAO interface containing all the methods that you want to call. For each database you connect to, I would build a new class that implements your DAO interface. This allows you to have multiple implementations. Then I saved these implementations (each of which has its own data source) on the map (java.util.Map), using your "logical properties" as the key to the map. Since all of your DAO implementations implement your interface, you can relate them to the interface and use them interchangeably. At your business site, you will be introducing Map of DAO. Hope this helps your design.

Answer 3

You might want to learn this class:

http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/jdbc/datasource/lookup/AbstractRoutingDataSource.html

This will simplify your service objects and data access objects that do not know that there is any concept of dynamic data sources.

Usually you need to implement a servlet filter and use ThreadLocal so that the DataSourceLookup implementation used by AbstractRoutingDataSource can easily access the query parameters that determine which DataSource will be returned. If you really want to avoid this, you can implement a servlet filter that sets the properties in the request bean and inserts that bean into the DataSourceLookup implementation that you wrote. Object-oriented beans still use ThreadLocal in their implementation, but at least that way it is Spring impl, not yours, and you don't need to worry about that. :)

A similar approach is detailed in this blog post from the Spring team:

http://blog.springsource.com/2007/01/23/dynamic-datasource-routing/

Answer 4

I had such a problem in a client / server project. Client and server projects used Dao interfaces. And when I used the database operation, I had to choose the appropriate Tao implementation. My solution was this:

IVehicleDao vehicleDao =daoFactory.Get<IVehicleDao>(parameters); vehicleDao.doSomething(); 

Get dao from Factory by passing parameters. Inside Dao Factory, decide which Dao implementation will be returned.

Answer 5

I've already done it. You need to create one DAO for each class, and in the area of ​​your DAO you need to pass DATASOURCE and, finally, one CONTROLLER class, where you make a dynamic call to the DAO.