2007-05-28 #1

Decorating a Good DAO

Eric Burke has a fairly good blog entry on Characteristics of a Good DAO (where a DAO is, of course, a Data Access Object).

However, he does offer one questionable piece of advice:

DAOs contain minimal, if any, business logic. Instead, just Create/Read/Update/Delete data. Placing business logic into a DAO is bad, because then you’ll have to duplicate that business logic if you ever provide an alternate implementation. Or you’ll find it difficult to write unit tests for your business logic if it is tightly coupled to things like JDBC or JPA.

While it would definitely be a bad idea to duplicate your business logic in multiple DAO implementations (or anywhere else, for that matter), this doesn’t mean that you shouldn’t have business logic in your DAO layer. Confused? Then you’re forgetting about the Decorator design pattern. A decorator delegates to another object which implements the same interface that it does; but not before adding some extra bit of functionality.

The correct thing to do would be to leave the underlying DAO implementations free of business-logic, just as Eric suggests, but then to add the required business-logic with decorators. You could replace the underlying DAO implementation without having to replace the business-logic layer(s).

This design maintains a good “separation-of-concerns” by having the underlying DAO implementations only concerned with the actual persistence, and having the decorators only being concerned with one particular aspect (ex. business-logic, logging, validation, authentication, caching, etc.).

Eric said:

A DAO should consist of an interface and one or more implementations.

but what he should have said was:

A DAO should consist of an interface, one or more implementations, and zero or more decorators.