In November 1998, Torsten Stanienda and I wrote an article for IEEE Computer that compared transparent persistence to a call-level interface. The article was based on an exercise Torsten did that compared the ODMG transparent persistence for Java to the JDBC call-level interface. Even though the article goes back some years, the results of Torsten's exercise are worth noting.
Torsten created an example set of classes for Person, Professor, Student, Course, and LectureRoom. He then wrote two sets of code to create, access, and manipulate objects in each of the classes. One set of code used the ODMG Java Binding and the other used the JDBC call-level interface. A summary of the results are shown in the graph below. For this exercise, 496 lines of code were needed using the ODMG Java Binding compared to 1,923 lines of code using JDBC.
What does this mean for you? Granted this is small example, but it does demonstrate the difference in the lines of code needed between transparent persistence and a call-level interface. This can be an advantage when it comes to development costs. The results can be extrapolated to Java Data Objects (JDO) or the ODMG C++ Binding. See transparent persistence (new window). For additional coding examples for transparent persistence, see how to access data in a relational database (new window).
Note that this example does not cover the development time needed to design the best mapping when using an object-relational mapping product. It also does not cover entering this information into the object-relational mapping product so that the mapping layer can be generated. Nevertheless, using transparent persistence with an object-relational mapping products significantly reduces development time. See development costs with object-relational mapping products (new window).
The article's title is "Solving the Java Storage Problem" and it can be downloaded from the IEEE Computer site (new window).
More on the general topic: Object-relational mapping (OR mapping) definition
