Think Objectively

What does ORM stand for?  Object Relational Mapping.

What is an Object?  Data and behavior.

What is a DAO?  Data access object.

If an Object is data and behavior, why is there such a thing as a "data" access object?  Why not an Object access Object?  Does a DAO have any place in an object oriented architecture?

Good questions.  I don't pretend to have the answers, but I have a few observations.

First, if you use DAO layer, then something has to reassemble your object model from the "data" you just accessed.  Now you have a DAO, a DTO and an assembler just to get data from a database into a usable object model.  Seems like a lot of work.  Also sort of inflexible to change as we are prone to omit details from the model that we are not currently interested in, and leave it up to the next person.

Second, hibernate is a good ORM but it has a steep learning curve and a few limitations.  There is no cure for having to learn things and I get that, but it's pretty weird that the ORM market is still evolving some 35 years after OO design and development began.  It seems pretty fundamental to software development to be able to get  and store data.  JPA is a "standardized" version of Hibernate, but eclipseLink and Hibernate implementations of JPA are not simply swappable.  Don't kid yourself, Oracle wants you to use EclipseLink and Redhat wants you to use Hibernate for a reason $$$$.  They aren't going to make it super easy to change things and cut them out of the loop.

Lastly, I personally would like to think the DAO is dead (DOA).  Spring ROO manual has a section dedicated to the demise of the DAO.  JPA gives a much cleaner transition from data storage to Object model.  It's not perfect, but far better than having three or four architectural layers dedicated to getting data.  Also, I have seen applications where Object classifcation/subclassing is left out altogether in the DAO layers just because it's difficult to implement in that way.  This leads to the visitor pattern to implement object specific behavior.  Now, maybe I'm wrong but doesn't it seem like a bad idea to have a travelling section of business logic that is seperate from the actual object model?  I guess I'd like to see the visitor pattern go the way of the DOA DAO.

l8r