Lightweight R/O Mapping

Limitations and Drawbacks

As with any tool or technique, the approach we've discussed has limitations.

• The elimination of XML descriptors leads to problems when the interface between the database and the object domain slightly changes. Actually, solutions with XML descriptors are only better off, compared to Amber, when the change only occurs in name, not in type, and if no property/field is added or removed. Otherwise both systems need recompilation and deployment.
• Compound management is not automatic. In fact, there are many things that are not automatic when you compare Amber with the big O/R guys. In business settings where the database is used as a dumb storage device and also where tables are joined in the middle tier, Amber will not be particularly useful. On the other hand, you could say that Amber is ready for dependency-injection-style programming and loose coupling between data, which many agree is better than implicit dependencies.
• Finally, annotation analysis and introspection are generally performance-hungry. In a setting where the application focus is on heavy database interaction (say, a concurrent user interaction middleware) rather than casual interaction with a single user or few users, Amber could lead to performance problems.

Conclusion

This article has demonstrated a reversed R/O mapping approach compared to conventional O/R mapping. The complexity of the mapping task, the so-called impedance mismatch between object-oriented and relational systems, has been reduced by defining the relational data model as the reference model for the object domain and by the utilization of stored procedures especially for task of writing objects into a RDBMS (Relational Database Management System). The mapping is implemented by annotations, a language feature of Java 1.5. This approach is supported and demonstrated by a framework called Amber.

Amber is a small framework, easy to learn and easy to use. There are just a couple of classes to be handled and they are very close to JDBC. The interfacing between database and JavaBean classes is accomplished via annotations. There is no need for XML descriptors anymore. Since XML is not easily readable by humans, this is a plus. That also means the mapping description between database and application lies in one single location, the bean class. Amber also provides a constraint checking mechanism to allow content validation, which is not discussed here to keep this article short.

Amber does one thing and it does it well: map database columns and query parameters to JavaBean properties. No more, no less. Amber is no silver bullet, and it does not solve the problems that are tackled by large, industry O/R frameworks.

Amber has proven its worth in a business environment. At Impetus, we've developed a sales force solution for one of Germany's largest mail order companies, in Java using MS SQL Server, that handles all database interaction with Amber. We've had no change in the API since its inception this spring (with the coming of J2SE 5.0) and there were no significant problems in using it.

Resources

• Amber project
• Amber: Sources
• Tiger: A Developer's Notebook, by David Flanagan and Brett McLaughlin
• JavaBeans
• JDBC
• Reflection
• Annotations
• " Object-Relational Mapping with SQLMaps," by Sunil Patil
• "Use Stored Procedures for Java Persistence," by Eric Bruno
• " Annotations to the Rescue," by Norbert Ehreke
• " An Annotation-Based Persistence Framework," by Allen Holub

Norbert Ehreke is a consultant and software developer currently affiliated as a senior development lead with Impetus Unternehmensberatung GmbH in Frankfurt, Germany.

Return to ONJava.com.