A case for the Generic lightweight DAO

This post stems from my research in how to correctly use hibernate3 in a spring-webmvc application. It outlines the various means to do so and proposes a rationale for using a generic lightweight DAO pattern. I have been spending some time researching the various ways of using hibernate3 with spring in a web app. The first thing I noticed is that there are multiple ways of doing that. The immediately obvious way is to inject the hibernate session factory in the various business components which would have to manipulate persistent data. This allows to work directly with the hibernate API, however it also means your business layer will become tightly coupled to Hibernate (think API usage all over the place) changing to a different orm later would be very hard. it also means code which is harder to test. The common answer to that is to use the DAO pattern (Not everyone agrees, see the ORM and the misleading DAO pattern at the serverside ). Supposedly it helps with the decoupling by centralizing the API usage in one place. On the implementation side however things tend to get messier than the theory predicts. Spring 2.5 proposes two ways to create DAO implementations :

• inheriting from HibernateDaoSupport
• using HibernateTemplate

Unfortunately they bring very little to the fight. HibernateDaoSupport offers almost nothing. it's a bare template for a DAO allowing sessionfactory injection and internally creating an hibernate template for inheritors to use, very little meat on this bone. HibernateTemplate has a lot more to offer but the way it's supposed to be used makes it next to useless : you are supposed to reimplement all the methods you want then delegate to hibernate template. I complained about this to a friend of mine whom I knew has been playing with these for a while now. His answer was that according to "purists" the DAO shouldn't expose more than what is required by the business, and that thus it was incorrect to make a generic dao implementation. While I agree, I still think this doesn't preclude a generic implementation of the DAO, the exposition is the concern of the DAOs Interfaces, this has nothing to do with implementation. The current implementations mean developpers must duplicate a lot of code to use a DAO. Sure there are considerations of backward compatibility with java 1.4, I still think a GenericDao implementation should be found in an optional spring lib somewhere. I hear it's coming with spring3.0 but what I have seen so far is not very convincing. It seems I am not the only one thinking along these lines, there are quite a few articles on the internet which show how to implement the DAO pattern using java generics to make for a DRY implementation. And there are at least two google projects proposing a small library implementing this pattern :

• http://code.google.com/p/hibernate-generic-dao/
• http://code.google.com/p/generic-dao/

I have settled for the former. The API seems simple enough, the design seems logical, only usage and time will tell now if I made the right choice... I'll publish the results of my experiments later on

Manifesto for software craftmanship

Following a blog post by Dave Carver which I found through planet eclipse. I have signed the Manifesto for software craftmanship. It values the following : Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships

VCS branching diagram

At last I have found a tool which makes branch diagrams easy enough to be formalized : yED It takes a couple seconds getting used to the UI: clicking drops a node by default, dragging creates an edge (at first you create a few unwanted nodes and edges) they have a very friendly palette system which allows you to define a node or edge archetype in a few cliks. Once you have defined you palette this is what you can get in a couple minutes: Alignement is handled automatically through the use of yED layouts. there are many many options, and I couldn't get it to do exactly what I wanted yet but I haven't read any doc either :) Definitely a tool I'll remeber for network and graph visualisation