This is not really a question concerning some kind of problem, but this is mainly an attempt to explore opinions and views regarding best practices.
Currently I'm working on a project in which I have choosen to implement the DAO design pattern, including a DAO Abstract Factory to facilitate the opportunity for datasource replacement (which, for this specific project, is likely to happen in the near future).
I have consulted the tutorial for the implementation of this design pattern as provided by the Core J2EE Pattern Catalog in which it is suggested to open (and close) a connection for every single query that is invoked through a method within a DAO.
However, would it not be better practice to open and maintain one single connection that is shared among all DAO's? The abstract factory could provide the instance of the connection object to the DAO's.
What are your opinions and views?
Thanks in advance!
[ February 11, 2007: Message edited by: Jeroen Oosterlaar ] [ February 11, 2007: Message edited by: Jeroen Oosterlaar ]
I'd recommend connection pooling on the server level. You would still open/close connections but they were limited by the size of the pool preventing runaway access. Also, for multiple-update transactions, you can't really commit until the end of the transaction, so you don't close the connection until you are done. Oh, and if you have data that you know is static in nature, there's nothing to say you can't create a static instance (or more properly JNDI object) that contains a cache of database information, periodically updated.
Make no mistake, database access if *often* the bottleneck of major applications regardless of the pattern you use. Anything that can intelligently reduce connections should be utilized.
Good luck on the pattern, even when done right it can be difficult, sometimes impossible, not to have to go back and re-write a lot of code to support a new database. I'd recommend trying an object-relational model if multiple database support is vital.
I was thinking of using Jakarta Commons DBCP to take care of the connection pooling. However, now that I am thinking about it, I might as well use a ORM solution such as Hibernate. Not only, as I assume, would it be easier to implement instead of a complete DAO and Abstract Factory construction, I am also very interested in ORM since it approaches the OO concept to the fullest. [ February 14, 2007: Message edited by: Jeroen Oosterlaar ]
Joined: Feb 11, 2007
An update! I have succesfully created a simple application (called Hibernote to store simple notes related to one category) using Hibernate. I must say that it is really cool!
I still use DAO's, however without a factory, to separate the Hibernate interaction logic from the business logic. Is the use of DAO's with ORM good practice, or should one completely get rid of DAO's when using ORM? [ February 17, 2007: Message edited by: Jeroen Oosterlaar ]
Jeroen, Obviously there is no right or wrong answer to your question. I don't see any harm in using the DAO with ORM. It protects your other code against change if you decide to use a different db technology in the future.