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? 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?
Posted by Matt Raible on November 26, 2002 at 11:51 AM EST #
Posted by Dave on November 26, 2002 at 12:14 PM EST #
Posted by Jason Carreira on November 26, 2002 at 04:50 PM EST #
Posted by Xavi Caballé on November 27, 2002 at 05:21 AM EST #
Posted by Dave Johnson on November 27, 2002 at 08: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
Posted by Shakeel Mahate on November 27, 2002 at 01:11 PM EST #
Posted by Sean on September 27, 2003 at 04:11 PM EDT #
Posted by Sean on October 11, 2003 at 11:07 AM EDT #