CodeFutures is often asked which data persistence techology should be used in a specific project.
The simple answer is: there is no perfect data persistence technology.
The choice depends on the project requirements, the skills of the development team, and if an organization has standardized on a specific data persistence strategy.
For clarification, CodeFutures provides code generation all of the technologies below. FireStorm/DAO can generate Java data persistence code using DAO or ORM style coding for JDBC DAOs, JDO, EJB CMP, and Hibernate.
All technology choices can be combined with the DAO design pattern – which is Core J2EE Design Pattern.
The only strong opinion offer by CodeFutures regarding data persistence technology choice is that if have a tight deadline, the lowest risk choice is JDBC DAOs.
-JDBC DAOs – Data Access Objects are a core J2EE design pattern – so it’s a sound approach (provided you’re not hand-writing the DAOs!). JDBC DAOs are most simple solution with the shortest learning curve.
Because you are using a design pattern, longer term maintenance costs are reduced because its easier to review and modify the code.
Also, JDBC is a mature and reliable technology – a safe choice.
There’s usually lots of engineers around with JDBC experience – which is an important practical consideration.
There are no runtime/deployment fees because you’re using POJOs (unless, for example, you decide to deploy in a J2EE application sever).
-EJB CMP – EJBs are more than just persistence, and often they must be used in projects because everything has to be written for a J2EE application server (e.g. internal coding and deployment standards). Not so bad if you’re generating the code.
Most J2EE products have runtime/deployment fees.
-JDO – the best data persistence specification. Problems with politics – even if the JCP vote on JDO 2.0 goes well, the specification has been damaged (which was the intention of the J2EE vendors that voted against it, I suppose). Using mapping tools for 200 tables would be a bit of a drag – but JDO is ideal for code generation so you can have your JDO code in a few seconds.
Some JDO implementations have runtime/deployment fees (although the code generated by FireStorm/DAO has no runtime/deployment fees).
The most positive news for JDO is that Apache is developing an implementation. There are several open source JDO implementations already available, but they have failed to gain the type of market momentum and developer community that an Apache project can often achieve.
-Hibernate – Without doubt, Hibernate has market momemtum with a certain developer profile – what Gartner calls Type A – the technology pioneers – who also tend to be the most vocal in newsgroups, etc. Remember this is a proprietary product – there’s only one implementation of the API and its not based on any industry specificaiton or standard – but you get the source code so you’ll never really be stuck.
There are no runtime/deployment fees for Hibernate.
CodeFutures already has a preview of Hibernate code generation available and in use by some customers and Hibernate was the headline feature in Release 3.0.
In terms of popularity among CodeFutures’ customers, JDBC DAOs are clearly the most popular.
This is good news – it means that developers are going for the simplest and most mature technology.