A Public Scratchpad

I draw my idea of the form of government software from a principle in nature which no art can overturn, viz. that the more simple any thing is, the less liable it is to be disordered, and the easier repaired when disordered;…

– Thomas Paine, Common Sense (1776)

A couple of weeks ago a colleague and I were discussing DAOs, and whether or not they could be eliminated in a minimalist approach to application architecture. Specifically, since JPA is essentially a standardization of the persistence layer, do you really need a custom persistence layer to wrap the standard persistence layer?

Coincidentally, InfoQ addressed this same question just a couple of days later, and it appears that a small portion of the JEE blogosphere has debating the issue for some time now. The consensus, which I agree with, is that it really depends on the application. If you have a relatively small domain model, it might be a good idea to forgo custom DAOs.

I’ve been experimenting with this approach in a small application which I’ve been developing as a pet project, and I’ve been very pleased thus far. The only aspect which makes me slightly uncomfortable is the sprinkling of JPAQL which now exists in my service layer. A criteria API similar to the one offered by Hibernate would, in many cases, be a good alternative to JPAQL, and I seem to remember having read somewhere that JPA 2 will include this feature.

So is it time to say goodbye to DAOs? Not at all. Anyone developing an application with more than a dozen domain objects should think long and hard before throwing time-honored best practices overboard.

But there’s a gray area somewhere in the spectrum between “homebrew CD collection tracker application” and “commodity market trading backbone.” As your domain model gets smaller and smaller, your DAOs will start to look more and more anemic, and it’s possible that at a certain point you may say “forget it, I’m going DAOless.” Just know that you’re not alone.