« WebSphere App Develo... | Main | java.blogs! »

Flexibility, Complexity, and DAO

If you use the DAO pattern, it is possible to completely hide your persistence mechanism from your application.  It is possible, but is it a good idea?  Separation of concerns and modularity are always good things, right? <a href= "http://www.freeroller.net/page/acoliver/20021125#excessive_over_engineering_flexibility_and">Andy Oliver argues that this is not always the case. I think he has a good point. You have to think about what you are trying to achieve. Sometimes separating concerns buys you nothing and just makes your system more complex.

In the case of the DAO pattern, the point is to separate the client portions of an application from the data access mechanisms and to allow the "data access mechanisms to change independently of the code that uses the data." I'm trying to understand the flexibility/complexity trade-offs of DAO. Here are the pros and cons I've assembled thus far:

Benefits of DAO pattern

  • The data access mechanism can change independently of the rest of the application.  This makes it possible for you to switch persistence frameworks without upsetting the rest of your application. That sounds great to me because I like to experiment with different persistence framework, but is it generally useful?
  • Another benefit is that you get an elegant and modular architecture, but that is pretty subjective. One man's elegant architecture is another man's spagetti-code mud-ball.

Drawbacks of DAO pattern

  • Adding an extra layer of interfaces to hide your persistence mechanism adds complexity and could even effect performance.
  • Completely hiding your persistence layer behind DAO interfaces may not be practical. For example, you'll want to use Castor's long transaction feature but in order to do so your persistent Java classes will have to implement org.exolab.castor.jdo.TimeStampable. Damn, your persistence engine just poked it's ugly head out from behind the curtain of DAO.
  • Different persistence frameworks may have totally different development paradigms and forcing them into the DAO pattern may force you to make sacrifices.  You will end up supporting leveraging only the least common denominator features of your persistence framework.
Personally, I like the DAO pattern and I like the idea that DAO can help you achieve a pluggable persistence layer. I like the idea that you can switch from EJB to Castor, and then from Castor to Hibernate if you wish to do so.

What do you think? Is the DAO pattern a good thing? Is pluggable persistence a desirable design goal?

Comments:

I use the DAO pattern on my current project, and it does work well, but I've never had to port to a different database, so I don't know that I need it. The one problem I see with it is that everytime we add a column to a table, I have to go and change all the SQL in my DAO's and add getter/setters to my VO's and Form objects. My ideal situation would be to have one POJO that generates the VO, Form, and DAO so I only have to add the column in one place.

Posted by Matt Raible on November 26, 2002 at 02:51 PM EST #

I agree, and the 'what does it take to add a new column/form-field' is a good measure of success. However, I don't think Value Objects really have a place in DAO, all you need is POJOs.

Posted by Dave on November 26, 2002 at 03:14 PM EST #

Hmm.. weird... I just blogged about inefficient DAOs... I went to make a long comment, then turned it into another blog post...

Posted by Jason Carreira on November 26, 2002 at 07:50 PM EST #

I am learning about the DAO pattern and, in the example code that I've seen so far (for example, the CatalogDAO interface), the DAO interfaces only have methods to get data from the database, NOT insert or update data. I think that DAO can also be used to abstract these insert and update functions, but then I think that maybe I still don't fully understand the pattern and there are good reasons (unknown for me) for not doing this. I would be thankful to anyone that could help me to clarify this question. Thanks (and thanks for your weblogs, and your weblog software)

Posted by Xavi Caballé on November 27, 2002 at 08:21 AM EST #

The DAOs that I have written do creates, removes, updates, and deletes. I think the CatalogDAO example recommends DAO for queries only, because Sun was recommending that all database updates go through EJB.

Posted by Dave Johnson on November 27, 2002 at 11:07 AM EST #

Isnt a Value Object a plain old java object?

Is there a difference in how the relationship between entities - 1-1, 1-many, many-many are managed in Value Object as compared to DAOs?

What I would like to see is a XSD schema based approach that drives the generation of everything underneath

  1. CMP EJB
  2. Session facade
  3. Value object
  4. Struts Action
  5. Struts ActionForm
  6. ...

Posted by Shakeel Mahate on November 27, 2002 at 04:11 PM EST #

DAO example code: http://daoexamples.sourceforge.net/xref/

Posted by Sean on September 27, 2003 at 07:11 PM EDT #

I published an article called "Advanced DAO Programming". Enjoy: http://www-106.ibm.com/developerworks/library/j-dao/

Posted by Sean on October 11, 2003 at 02:07 PM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed

« WebSphere App Develo... | Main | java.blogs! »

Welcome

This is just one entry in the weblog Blogging Roller. You may want to visit the main page of the weblog

Related entries

Below are the most recent entries in the category Java, some may be related to this entry.