This post originated from an RSS feed registered with Java Buzz by Marc Logemann. Original Post: Why use DAO layer with ORM solutions? Feed Title: Marc's Java Blog Feed URL: http://www.logemann.org/day/index_java.xml Feed Description: Java related topics for all major areas. So you will see J2ME, J2SE and J2EE issues here. Latest Java Buzz Posts Latest Java Buzz Posts by Marc Logemann Latest Posts From Marc's Java Blog

I am really questioning the usage of a DAO layer in a J2EE app where you have also a business service layer and a ORM solution. DAO is a nice concept, but its main purpose is to shield developers from the SQL hell and add implementation change capabilities when you dont use ORM. So when using JDO or hibernate or whatsoever, you are duplicating nearly the same code, lets see:

Web ActionHandler: calls userService.getUsers()
userSerivce: calls userDAO.findAll(); (only line in getUsers())
userDAO: findAll() is a three liner with JDO statements

I cant see a problem to put the JDO stuff inside the userService Methods, because JDO itself is the needed abstraction normally got from DAOs. DAOs are extremely important when you dont have an ORM or general abstraction layer over SQL, because then you can swap a userDAO based on MySQL with a userDAO based on Oracle on application setup.

So right now i am evaluating to remove this DAO stuff, because it adds hundreds of classes and interfaces without much gain. If i want to change the database, i dont do it via changing the implementing DAO classes but with a JDO style configuration change. DAO would also make sense to abtract your application from the ORM product used, but how many times you change this in a big application. This lets me think of phantom requirements mentioned in "J2EE without EJB".