(Please note: “Persistence tools / frameworks” used throughout this entry refers to Hibernate, JDO, iBATIS, SDO, etc. I’m not considering JDBC to be a persistence tool for this entry.)
The risk associated with the persistence tools is very high given the state of flux that the industry is in (especially with EJB 3.0 coming out in the “near” future). Remember that choosing a technology isn’t just based on the cost to implement it today. It is based on the total cost which also includes all of the facets of maintenance and change.
If I had a project that had a persistence component and I knew that I was going to be actively developing and maintaining it for at least 2 years, I would likely use JDBC. Let’s look at some of the factors involved in my decision:
- The persistence frameworks are all going to change significantly over the next two years especially with EJB 3.0 coming out. The same goes for the various query languages that they expose.
- New persistence technologies may come out that replace the incumbents redering them effectively dead. (I’m concerned less about this with Hibernate than I am with, say, JDO. But that’s just a gut feeling based on the number of people using it, exposure, etc.) If IBM does what I think it will do with SDO, for example, then the space will change dramatically.
- The learning curve with most of these persistence tools is very high. Some may poo-poo this, but if you do anything beyond “just the basics” then you’re investing a LOT of time learning, debugging, and posting on forums. *grin*
- The maintenance efforts and risks for the persistence tools are not well understood. Given that the tools themselves are still in flux, the techniques and skills needed to maintain the tools and associated code are also changing.
- JDBC, for the most part will remain unchanged. It is a known quantity with known risks and the maintenance efforts and associated risks are well understood.
- There is no “specialized training” associated with JDBC. I don’t have the “hit by a bus” problem with JDBC that I have with the other persistence tools.
My job as a development manager is to produce software with the lowest total cost and the lowest risk. To me, JDBC is still the clear winner for the cases that I stated earlier.
I should point out that if you’re prototyping an application, working on certain types of one-off application, or working on a application with a severely limited lifetime then the RAD aspects of the persistence tools may work to your benefit.
If you disagree, let’s hear it!