I'd like to evaluate the Object/Relational Mapping approach and products. Any discussion is helpful.

Matt Goodall

jguru Disclaimer: The following views and opinions are entirely those of the respondents and provided for our readers to consider. jGuru is not in the business of evaluating products.

Disclaimer: I'm still in the process of evaluating some of these tools so you should do your own tests before making any final decisions.

I think an O/R mapping tool could help a lot. After all, there is nothing more tedious and error prone than writing code to move data from a database to a Java class and back again!

If you are lucky enough that you have a database schema that reflects the object model reasonably well then I think these tools will help a lot.

Unfortunately, I think I'm coming to the conclusion that it is not worth trying to use these tools with a legacy database. By legacy, I mean one that was never designed in an object-oriented way. Instead, you should probably use a DAO approach.

I've looked at quite a few: TopLink, CocoBase, OJB, Castor. Of those, I favour TopLink and OJB. OJB is open source, if that appeals, and is nearing a 1.0 release. It's continuously improving, has active development and the lead developer is extremely responsive to both suggestions and bug reports.

You need to choose carefully. In particular, think about how you want to manage connections and transactions. Perhaps you want to use these tools inside an EJB container and take advantage of the container's transaction management?

Unless the application is fairly simple, I suspect there will always be the need for writing JDBC but hopefully that would be the exception.

I would recommend reading Scott Ambler's white papers on the subject, just to get a feel for what an O/R tool should do:

There is plenty more information on the internet. Please post your findings back here.

Jay Meyer adds: I have used Toplink in a large Weblogic environemnt, and it has good and bad points. You were right: do NOT use Toplink on a legacy database, it will not be able to handle some of the complex relationships. We ended up redesigning some tables to make Toplink work with our old schema. But once we did that it would gen the EJBs and change tables anytime we needed to add columns or tables to the database. This was useful in the large dev team. The downside to Toplink or any O-R mapping tool is that you invariably have to learn yet another query language. Toplink's query builder was really hard to understand especially when you have dozens of programmers who already know SQL and want to use SQL directly. For our next project, we used the Ambler persistence (mentioned in Matt's message) technique and wrote our own mapping classes. It turned out to be about the same amount of work/time as installing/configuring Toplink, we just needed some skilled Java/JDBC programmers to build it. But now we have full controll over queries and performance using the JDBC calls and we do not have to figure out Toplink's cryptic product.

Christopher Schultz adds: Although they don't seem to be common, Object Databases are a viable option. Some people say they are slow, but O-R mappings are difficult to write/maintain/understand. Check into Versant and others for an object database and see what they have to offer.

Joe Sam Shirah adds: Object databases are certainly an option, but there are many reasons the relational model has remained the data backbone. My own opinion is that when evaluating an object database, an important criteria should be that it also supports the relational model as much as possible.

Another open source O/R tool to review is the Java Layered Frameworks ( JLF ).