This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I have been on asking a few questions in the last couple of weeks, and i got a few good answers so i'm gonna try again. I need a suggestion on how to set up a proper DAO for the following situation.
I may have different db connections (MySQL, SQLServer, Oracle) sounds like factory pattern, but i may also have Web Service, and XML File I/O DAO's as well. Then i have something i called a User Defined DAO where i use java reflection and an XML file accessed with XML Beans, to pull out connection info and connection logic, and return a HashMap of Info. In this DAO there is only one method and it will execute whatever logic it finds in the XML file through reflection. That is so that users aware of the data they need can create a query and get a resultset back without needing to change compiled code, XML files on the server are refreshed dynamically. The XML would contain things such as expected parameters, and SQL, or Web Service method info and parameters...etc
Obviously Factory Pattern wont work because different types of DAO's will not all implement the same interfaces. And how should my Connection Management work if i might be connecting to any number of Databases simultaneously. I should have a connectionPool for each type Database i might connect to? I just want to do this as proper as possible, so i ask for opinions....
Thanks in advance
Greg B [ March 09, 2005: Message edited by: Greg Belyea ]
Greg, Would a connection pool work? It sounds like some of the DAOs (reflection based and XML) wouldn't have a connection.
If possible, I would have all the DAOs implement a common interface. If not, I would add an adapter that has a common interface and calls the DAOs. One of those adding a level of indirection to solve the problem things.
As far as XML and WebService not having a connection, they will have connection or call protocol just not the same way as a DB connection. I will need to look further into connection pooling in order to understand how to have open pools of connections to different db's at the same time...
As for the second part of your paragraph it is impossible for my DAO's to implement the same interface because they definitely won't have the same methods in them. There will be a certain aspect of the application that will use a db for storing transaction state, and that would be the same across the board. But that is a very small part of the application, the majority of information will be obtained via Web Service calls, XML File I/O, and user defined methods executed via reflection, meaning the DAO method is generic and is unaware of the method it is executing. The latter is also completely unaware of what DB it is calling, that info was contained in the XML doc the user defined, they simply specify a database name, and a method, and a few parameters, and i make the appropriate connection and return a hashmap to the user........ I am thinking this set-up is a bit unorthodox, and no clear pattern would exist for me to use.
author & internet detective
Greg, It sounds like these DAOs do different things. (Originally I thought they were different implementations of the same thing.) This explains the different signatures in which case an interface wouldn't work completely.