This is actually a very interesting discussion. On the
SCEA board, we had a discussion on "Which
J2EE Design Patterns are Obsolete with JEE5?" Many people felt the desire to kill the DAO pattern.
I agree that there is great value in separating the data layer from the application layer. I mean, that's just a given. But indeed, POJO based persistence does make the need for making DAOs every time questionable. And the fact that DAOs can be made to be so generic, it again almost begs the questions "what's the point?"
The other thing I find very interesting is that many places using the DAO pattern to hide their implementation layer from the application or service layer typically have a search method that passes in a org.
hibernate.criterion.Criterion object. Now correct me if I'm wrong, but doesn't passing a
hibernate criterion object defeat the purpose of creating DAOs that hide the implementation layer from the application integrator or service layers? Always makes me giggle.
One thing I will say is that most application integrators are very familiar with DAOs, and if you provide them, they can use them. Even if the only benefit is the ability for
JSF or middleware developers to be able to start using them quickly and effectively, well, that's probably a pretty good argument in itself.
I provide a little tutorial on my website on how to create generic DAOs that leverage the good old Java 5 Generics, along with the Factory and ServiceLocator design patterns. Very old school, but the tutorial is a bit simpler than the ones you might see in the Caveat Emptor application. If anyone is interested, it's right here:
Implementing Simple DAOs with Java5 Generics, Hibernate3 and Java Persistence API Annotations (JPA) -Cameron McKenzie
[ June 13, 2008: Message edited by: Cameron Wallace McKenzie ]