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 :
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
0 commentaires:
Enregistrer un commentaire