aspose file tools*
The moose likes JDBC and the fly likes DB interaction in a DAO and Abstract Factory implementation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "DB interaction in a DAO and Abstract Factory implementation" Watch "DB interaction in a DAO and Abstract Factory implementation" New topic
Author

DB interaction in a DAO and Abstract Factory implementation

Jeroen Oosterlaar
Greenhorn

Joined: Feb 11, 2007
Posts: 12
Howdy fellow Java software engineers,

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!

Kind regards,

Jeroen Oosterlaar

[ February 11, 2007: Message edited by: Jeroen Oosterlaar ]
[ February 11, 2007: Message edited by: Jeroen Oosterlaar ]
Scott Selikoff
author
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3716
    
    5

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.


My Blog: Down Home Country Coding with Scott Selikoff
Jeroen Oosterlaar
Greenhorn

Joined: Feb 11, 2007
Posts: 12
Thank you for your reply!

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 ]
Jeroen Oosterlaar
Greenhorn

Joined: Feb 11, 2007
Posts: 12
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 ]
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30955
    
158

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: DB interaction in a DAO and Abstract Factory implementation