I've been thinking recently about the merits of continuing to create DAO objects and layers in our applications. Especially since the fact that developers will cut-and-paste from a pre-existing DAO which is a particular antipattern that sets alarms going in my head. So Java 1.5 helps greatly because you can create a single type-safe generic DAO or PersistenceManager using generics.
However, the thinking in this area has progressed even more than I expected. Domain Driven Design (DDD) and Repositories offer a higher level of abstraction than DAOs and look to be more useful in an application using JPA or some other form of OR Mapping.
This post by Debasish Ghosh and it's related comments are a great summary of the argument.
This summary on InfoQ is also worth a read.
Through all of these arguments the important point to remember is that you still need to keep your domain model separated from how it's persisted. We may move away from the DAO pattern but making sure your application is layered correctly is still very important whatever it's called.
Did video kill the radio star? No, however their job changed slightly and they're called DJs now.
Friday, 8 August 2008
DDD Killed the DAO Star
Subscribe to:
Post Comments (Atom)
Posts
1 comments:
Speaking of layers and DDD: I have been playing around with directly mapping layers to Java packages up front, to help guide me. And I think it works quite well.
I.e. take the 4 DDD layers and create packages, e.g. myapp.ui, myapp.application, myapp.domain and myapp.infrastructure.
When I then think about where to put something, I have these 4 buckets - where before I might think I can get away with lumping it all into one package and refactoring later.
Obviously, once things are in packages like that, JDepend gives you some very clear answers about your coupling and cohesion, which is a nice benefit.
Post a Comment