• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

DB interaction in a DAO and Abstract Factory implementation

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Jeroen Oosterlaar
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic