Search code examples
design-patternsdaodata-access-layermultiple-databases

Design of DAO to access multiple identical databases

I am currently in the process of designing an application that is supposed to access multiple devices and collect various data. The data is stored inside databases (one database per device) which are totally identical (tables, views, functions, stored procedures, ...), despite of the data itself. ;) There can be up to 10 devices which may be connected or disconnected at runtime.

Now the question is, how to design the data access layer? At the moment I'm thinking about two approaches:

  1. One DAO per device, which results in 1..10 instances, where each one holds the connection information (stateful).
  2. A single DAO which accesses all devices by receiving the connection information per method call (stateless).

The application is supposed to be multithreaded (concurrent database access) while the performance is not critical, meaning that some locks inside the code were acceptable. The devices are only accessed on demand by the user. Since I'm coming from the RESTful Webservices side of life, I'm currently favoring option 2, because it is stateless.

Solution

  • The first thought that comes to mind is why not store all your data in one database and create a "device" table to differentiate your data per device? But that was not your question and I bet you have a good reason for it.

    Personally, I'd create a factory that returns the proper DAO based on the 'device' (device id?). That DAO would then have to already know the connection info, so I would store/configure that with the DAO or inject a session factory per database if you are using Hibernate or some other ORM.

    With the stateless solution you are just moving the 'problem' of storing the connection/db info to a different location. I think that info conceptually fits best with a DAO or session factory.