Multiple DAO's vs One DAO with configuration file

I'm currently in the process of creatin开发者_运维技巧g a data access layer for an application. This application will initially connect to an Oracle database but will later also connect to a DB2 database.

For connecting to the database I will use JDBC. At this time I'm considering my options. As I see it I have two (primary) options.

1) Create a design with support for multiple DAO factories, each instantiating the DAO's specific to their database. Initially, this design will only have one factory. Later it will be extended with a second factory and DAO classes.

2) Create one DAO factory which instantiates multiple DAO's for the different models. This DAO factory builds the DAO's based on a configuration file, which contains the JDBC driver path and connection url.

I'm tempted to choose the second option, which seems to remove quite some code duplication in the DAO's. Could anyone give the pros and cons of both approaches?

Why would you choose for multiple DAO factories (abstract factory pattern) when you don't really need it when using JDBC?

---

I believe Spring or Guice would be the best and cleanest option for you, where you'd want to pick the appropriate DAO implementation and inject it in the DAO consumer layer. Spring will also enable you to use Spring-JDBC which takes care of most of the boilerplate code making your DAO Impls easy to manage and code. You can also use ORMs with Spring.

---

Taking into account that you can't use Spring (even though it would save you from a lot of coding), I would say that 2nd variant is more appropriate to you, because you are going to implement dependecy management yourself and 1 dependency (single DAO factory) is always easier than 2.

Though, if you expect that amount of places were DAOs for both databases are used together is not big, then separating them into 2 factories will have a better structural meaning and is more clean. But if you expect, that pretty much every class that uses DAOs will need both worlds (Oracle + DB2), then again stick to the 2nd variant.

In any case, try to consider again about dependecy injection framework usage, because that what you are going to implement yourself anyway with all your factories.