Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 217 posts at DZone. You can read more from them at their website. View Full User Profile

Do We Really Need the DAO?

12.23.2012
| 10339 views |
  • submit to reddit

This may seem like a stupid question, especially after years of carefully creating them. Yet these thoughts about DAO arose in my mind when I watched Adam Bien’s Real World JavaEE rerun on Parley’s.

In his talk, Adam says he doesn’t use DAOs anymore – even though he has one ready so as to please architects (them again). My first reaction was utter rejection: layered architecture is at the root of decoupling and decoupling is a requirement for an evolutive design. Then, I digested the information and thought, why not?

Let’s have a look at the definition of the DAO design pattern from Oracle:

Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.

Core J2EE Patterns – Data Access Object

Back in the old days, either with plain JDBC or EJB, having DAO was really about decoupling. Nowadays and when you think about that, isn’t it what JPA’s EntityManager is all about? In effect, most JPA DAO just delegate their base methods to the EntityManager.

public void merge(Person person) {
    em.merge(person);
}

So, for basic CRUD operations, the point seems a valid one, doesn’t it? That would be a fool’s conclusion, since the above snippet doesn’t take into account most cases. What if a Person has an Address (or more than one)? In web applications, we don’t have the whole object graph, only the Person to be merged, so we wouldn’t merge the entity but load it by it’s primary key and update fields that were likely changed in the GUI layer. The above snippet should probably look like the following:

public Person merge(Person person) {
    Person original = em.find(Person.class, person.getId());
    original.setFirstName(person.getFirstName());
    original.setLastName(person.getLastName());
    em.flush();
    return original;
}

But what about queries? Picture the following:

public class PersonService {
 
    public List<Person> findByFirstNameAndLastName(String firstName, String lastName) {
 
        CriteriaBuilder builder = em.getCriteriaBuilder();
 
        CriteriaQuery<Person> select = builder.createQuery(Person.class);
 
        Root<Person> fromPerson = select.from(Person.class);
 
        Predicate equalsFirstName = builder.equal(fromPerson.get(Person_.firstName), firstName);
 
        Predicate equalsLastName = builder.equal(fromPerson.get(Person_.lastName), lastName);
 
        select.where(builder.and(equalsFirstName, equalsLastName));
 
        return em.createQuery(select).getResultList();
    }
}

The findByFirstNameAndLastName() method clearly doesn’t use any business DSL but plain query DSL. In this case, and whatever the query strategy used (JPA-QL or Criteria), I don’t think it would be wise to use such code directly in the business layer and the DAO still has uses.

Both those examples lead me to think DAO are still needed in the current state of things. Anyway, asking these kind of questions are of great importance since patterns tend to stay even though technology improvements make them obsolete.

Published at DZone with permission of Nicolas Frankel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

André Pankraz replied on Tue, 2012/12/25 - 7:55am

Hi

Think also about complex access rights, data access logging, special caching where JPA-cache doesnt fit etc. etc.

I don't want to distribute this kind of stuff into x controllers and nobody has a clue about where SQL is triggered in which form. Aspects etc. will also not be sufficient for this or are even more complex than classic DAOs.

Don't know what projects Adam is really involved into...his talks are great and funny but this "no layers - huray" doesn't really work for complex businss apps.

Yes...we don't need 10 layers etc, but DAO really has it's uses.

Cheers,

André


Francisco Lozano replied on Tue, 2012/12/25 - 1:41pm

DAOs are crucial in most cases. I bought the "no DAOs - hooray!" stuff sometime ago for a fast-evolving project... and I miserably regretted later, having to do huge refactors to re-introduce the DAO layer to clean the mess.

Alex Soto replied on Tue, 2012/12/25 - 1:45pm

Hi obviously it seems that more often than not DAOs are more a nuisance than other thing. I suggest for example taking a look of spring data, really nice project which helps you improving the way we write DAOs (it simplifies a lot persistence layers). Also it is interesting Active Record pattern which put database logic into model itself. I write about this topic some time ago by implementing this pattern using ITD if you want you can take a look: http://www.lordofthejars.com/2011/09/bell-that-rings-inside-your-mind-is.html

So as you said it seems that for now DAO pattern is still necessary, but there are "some kind" of alternatives or different approaches.


Cheers,

Alex.

shurui liu replied on Tue, 2012/12/25 - 11:49pm

If you are working on a product, DAO layer definitely is needed to cater for different database  due to syntax differences at least for report purpose.

Dejan Markovic replied on Thu, 2013/01/10 - 4:55am

Hi,

If you are using JPA the EntityManager is good enough implementation of DAO pattern, you most likely do not need your own. 

I would consider to use some other pattern like Repository for the problems posted here.


Br,

Dejan

shurui liu replied on Thu, 2013/03/14 - 11:32pm

It depends on your architecture. DAO patterns is not needed in CQRS + ES architecture.

Claude Bernard ... replied on Wed, 2013/11/20 - 1:00pm in response to: Dejan Markovic

+1

DAO pattern is obsolete in many areas since the provision of new components and dev techniques in java 5+ : generics, JPA and parameterized Types. This pattern must be revised and replace by a clear presentation of JPA as a superset solution.

I am frustrated to see that Oracle still keep annoying questions on DAO pattern in Java 6/7 certifications. 

I have never like the pervasive code caused by DAO pattern : one DAOObject for one Entity(TransferObject). That means for big applications using 300 entities, you have to define 300 DAO interfaces + related implementations. 

All this is solved by JPA : 

  1. you don't need to be concerned by the DataSource encapsulation (provided by JPA)
  2. the JPA entity manager provide all needed implementations for all those 300 DAO interfaces with 0 line code 
  3. You can use strategy pattern here to define a generic DaoService that can do CRUD operations on any entity, using composition on entity manager object :
    1. void create(T e)  
    2. T find(class<T>, C id)
    3. void update(T e)
    4. void delete(T e)
And JPA support many types of DataSource : Database, XML, ... 

Check EclipseLink or Hibernate

regards,

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.