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? 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?

Main | Next day (Nov 27, 2002) »