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.

Links

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.

Information
Januar 14th, 2009
14 Responses
Feeds and Links
Comment Feed
From This Author
Del.icio.us
Digg
Technorati
Categories and Tags
Hades
IT
, , , , , ,

Other Posts

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Comment Number:
1
Written by:
Mario Gleichmann
Posted on:
15. Januar 2009 at 10:45

Nice write-up!

I had some similar thoughts back in 2007, when the debate starts with the rise of JPA …

You may want to take a look at
http://gleichmann.wordpress.com/2007/11/22/why-dao-wont-die/

Greetings

Mario

Comment Number:
2
Written by:
raveman
Posted on:
15. Januar 2009 at 12:06

“Don’t repeat the DAO!” is the best one, i think only about 5% of DAO is used more than once. You could always extract method, but that would be too hard for some people (I know refactoring is hard to learn), so lets just use dead idea. DAO is dead, sorry.

Comment Number:
3
Written by:
Michael Plöd
Posted on:
15. Januar 2009 at 13:41

Raveman, I think you totally miss the point here. Using a properly written DAO (with Generics, Inheritance, Interfaces…) you are able to group all the standard CRUP operations in the abstract superclass. In addition to that you are able to establish project standards in how to use the API of an OR Mapper (remember session.merge vs session.saveOrUpdate in Hibernate? ). In my eyes the DAO is far from being dead.

@Oliver: thanks for the nice feedback and: nice writeup!

Comment Number:
4
Written by:
Graeme Rocher
Posted on:
15. Januar 2009 at 21:43

JPA didn’t kill the DAO, you still have to wire together all those dependencies. GORM did however: http://grails.org/doc/1.0.x/guide/5.%20Object%20Relational%20Mapping%20(GORM).html#5.3%20Persistence%20Basics

Comment Number:
5
Written by:
let x=x › Does JPA kill the DAO Pattern?
Posted on:
16. Januar 2009 at 14:40

[...] Gierke definitely thinks not. And I concur with [...]

Comment Number:
6
Written by:
snoobab
Posted on:
20. Januar 2009 at 22:48

DAO is a low level mechanism. It feels like we should start looking at a higher level of abstraction and get better benefits from our modelling; something like the Repository and Aggregate patterns described in Eric Evans book ‘Domain Driven Design’!

Comment Number:
7
Written by:
Oliver Gierke
Posted on:
20. Januar 2009 at 23:10

@snoobab – Thanks for your comment. DAO is widely regarded as synonym for Eric Evans’ Repository. So I do think, too. By creating a technology neutral interface for a DAO you actually take the step from a database abstraction towards a repository for entities.

Regards,
Ollie

Comment Number:
8
Written by:
Clinton Lee
Posted on:
21. Januar 2009 at 00:51

I agree, DAO layers need to still exist despite these ORM technologies. We had JDO in my companies application abstracted away via a DAO. When our JDO vendor was failing our requirements, we decided to (for a number of technical and feature reasons) switch over to a JPA vendor. We probably spent just as much time, if not more, in research and estimation than actually coding over to JPA. We then came in way under time and budget… There is no way we could have done this in such time without our persistence being abstracted into a DAO.

Yesterday it was JDO, today it’s JPA, who knows what tomorrow will bring? (db4o anyone?) So even though these are common interfaces, at times the common interfaces change.

Comment Number:
9
Written by:
Lava Kafle
Posted on:
21. Januar 2009 at 05:58

I did not see any forums on Hades site that you linked.

Comment Number:
10
Written by:
snoobab
Posted on:
21. Januar 2009 at 10:48

@Oliver: Yes agree that you can view DAO as Repository. The problem is that generally people don’t follow the other ‘good’ principles referred to in DDD in that typically business rules are implicitly coded into the DAO’s and there isn’t an over-arching thought process such as Aggregate pattern.

What therefore tends to happen is that new developers to a particular project will search for any DAO, instantiate the factory and start obtaining data, which may completely bypass any constraints or business rules.

Cheers
snoobab

Comment Number:
11
Written by:
Oliver Gierke
Posted on:
21. Januar 2009 at 11:19

@Lava – you have to be registered to create new forum posts. There should be link on the upper right corner where you can do this. Once you’ve registered, you should see a link saying “Create new post” or something like that. Hope that helps out. Feel free to contact me directly, if you have questions.

@snoobab – I second that entirely. The problem actually results from the habit to place business logic that is actually tied to the domain objects into services, which in case can be worked around by simply accessing the DAO or repository. As Hades can not enforce the domain driven design of entities we chose DAO as term. Repository would imply a domain driven view too much. Don’t get me wrong – I really like to leverage DDD. But we do not want to imply guidance that we do not give actually ;).

Ollie

Comment Number:
12
Written by:
magomarcelo
Posted on:
5. Februar 2009 at 13:29

I find Hades really interesting, but what about existing domain classes where I cannot implement a given interface like Persistable? Is ther a solution to have them not depending on Hades maybe using AOP?

Comment Number:
13
Written by:
Rogério Liesenfeld
Posted on:
12. September 2009 at 16:48

Oliver, you have misunderstood the wikipedia article on DAO.
Specifically, the part where it says “…, providing some specific operations …”.
The word “specific” in this context means operations specific to individual domain entities, not general-purpose operations like “persist(o)” or “remove(o)” that can be called for any domain object “o”.

This is stated more clearly in the parts that say “… domain-specific objects and data types (the public interface of the DAO), …” and “… specific DBMS, database schema, etc. (the implementation of the DAO)”.

Comment Number:
14
Written by:
Oliver Gierke
Posted on:
13. September 2009 at 11:27

Hey Rogério,

I tend to disagree as the sentence you quote does not even mention the term “domain object”. Thus IMHO “specific” means pretty much “database specific operations”. The reason I come to this conclusion is the question why anyone would bind functionality specific (meaning tightly bound) to the domain object to a separate concept interface? The DAO’s responsibility is to encode *persistence specific* aspects to not bother the domain objects with functionality not related to its core responsibilities.

As the article moves on wih a second sentence you also quote here it should become clear, that having a 1:1 relationship between a DAO and a domain object is not strictly necessary. As I understand the paragraph this just describes that the interface of a DAO is equiped with domain types and its purpose: hiding database (or perstistence technology related) specifics from clients unsing it.

Regards,
Ollie