The DAO is dead! Long live the DAO!
Episode 121 of Software Engineering Radio deals with the topic of OR Mappers. Michael Plöd introduces the concept of object-relational mapping technologies, discusses advantages and disadvantages. The content of the episode is very basic to a large extend, which makes it ideal to get an introducing idea of the topic.
The reason I discuss this here is a discussion Arno (the interviewer) is introducing regarding the necessity of the DAO (Data Access Object) Pattern, if you use OR Mappers. Michael thinks that the DAO Pattern still has the right to exist and I decidedly second that. Let me explain why…
First, let’s take a look at the origin of the DAO Pattern, the problems it was meant to address in times it was invented. According to Wikipedia DAO is defined as follows:
…a Data Access Object (DAO) is an object that provides an abstract interface to some type of database or persistence mechanism, providing some specific operations without exposing details of the database.
In the days it was invented “persistence mechanism” was equal to “JDBC and SQL”. This of coure has changed a lot if you use an OR Mapper or even another abstraction layer above it like JPA. As they provide a more object oriented view on persistence or even a standardized interface. Nevertheless I definately propose the DAO for a lot of reasons. In the podcast Michael coins two main reasons, that I will briefly will describe here. Furthermore I’m going to add some other ones.
Separation of persistence logic and business logic
Using JPA in your service class directly (whether it is a Statless Session Bean or Spring bean) works well as long as you can rely on the really basic CRUD methods: create, update, delete, read. Reading persistent objects already is not that simple anymore.
Tangled code / More sophisticated API
I have never seen an application that did only read all objects at once. You always need to select objects based on a given criteria, sort, page results and so on. If you try to set this up with JPA API or a vendor specific one you tangle your code with persistence code probably even proprietary API (if you use OR Mapper API directly). Furthermore you can easily mix and match persistence technology, if it becomes handy. I’ve seen few projects that use OR Mappers for classic data access and low level JDBC code to perform bulk operations.
Exchange implementation
This is the “Yessss… but who does this?” argument. The answer is: You do! Or at least you should. Unit testing your business logic you should be able to easily mock or stub out your data access code.
Don’t repeat the DAO!
Another aspect of the problem is that CRUD code as well as DAO implementations tend to be boilerplate. Repeated code here and there. Using a DAO layer allows you to gently generalize the code and thus reduce the amount of coded needed to implement it.
Hades to help!
Why am I so passionate about this? If you read my blog now and then you know that I lead project Hades that addresses exactly these issues. So if you ever have experienced one of the issues mentioned above, take a glance at Hades and play around with it if you like.
If you are from Frankfurt/Main area you have the chance to get introduced to it tomorrow evening where I will give a talk on Hades (and the DAO question) on 2009’s first DevDusk - Technology for Techies, a bimonthly meeting of passionated geeks, nerds, techies, whatever you wnt to call them. Would be nice to see you there.
