CodeFutures Corporate Weblog

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 provide 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 a 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.

The big news for CMP is that the Java persistence section of the EJB 3.0 specification is expected to gain widespread support. It is currently in draft format and will hopefully be approved in late 2005 or early 2006. CodeFutures will support this specification as soon as it is approved. Since the specification is in draft format and subject to change, it's not clear how much will be changed before it is approved. Also, as with all efforts at introducing a new specification, there will be mistakes, errors and omissions. This is part of the natural evolution of all standards and specifications. In the longer term, this new specification is a candidate for being as widely used and accepted as the JDBC specification.

-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.

CodeFutures already has a preview of Hibernate code generation available and in use by some customers and Hibernate will be the headline feature in Release 3.0.

The Future: SDO

CodeFutures has been looking at the Service Data Object specification since it was released by BEA and IBM. It certainly looks more attractive that EJB 3.0 persistence. But at the moment, we are waiting to see if there is any market momentum.

If you are moving towards a service-oriented architecture, then SDO certainly looks like the best choice.

The Present: JDBC DAOs
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.

PJ Murray
CodeFutures Software