CSC/ECE 517 Fall 2007/wiki2 2 22

Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).

Introduction

What is ORM?

Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers. For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once. Typical ORM systems will map one row in a table in the database to an object in the application and viceversa.

ORM Implementations

Ruby's Active Record

Major features of Active Records

• Automated mapping between classes and tables, attributes and columns.
• Associations between objects controlled by simple meta-programming macros.
• Aggregations of value objects controlled by simple meta-programming macros.
• Validation rules that can differ for new or existing objects.
• Acts that can make records work as lists or trees
• Callbacks as methods or queues on the entire lifecycle (instantiation, saving, destroying, validating, etc).
• Observers for the entire lifecycle
• Inheritance hierarchies
• Transaction support on both a database and object level.
• Reflections on columns, associations, and aggregations
• Direct manipulation (instead of service invocation like hibernate)
• Database abstraction through simple adapters (~100 lines) with a shared connector
• Logging support for Log4r and Logger

Hibernate

Hibernate supports key OO features

• Hibernate supports natural OO idiom; inheritance, polymorphism, composition and the Java collections framework
• It supports fine-grained object models - a rich variety of mappings for collections and dependent objects
• There is no extra code generation or bytecode processing steps in build procedure
• Hibernate is extremely performant, has a dual-layer cache architecture, and may be used in a cluster
• Hibernate addresses both sides of the problem; not only how to get objects into the database, but also how to get them out again
• Hibernate supports both long-lived persistence contexts, detach/reattach of objects, and takes care of optimistic locking automatically
• Hibernate implements the Java Persistence management API and object/relational mapping options (EJB 3.0), two members of the Hibernate team are active in the expert group

Oracle TopLink

Oracle TopLink delivers complete Java Persistance platform by providing following main features:

• Access relational data using JPA and many advanced object-relational extensions
• Efficiently manipulate XML through a Java domain model using JAXB
• Interact with unstructured data through Service Data Objects (SDO)
• Expose relational datbases flexibly using Web Services

JDO

The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence,

• Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.
• Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.
• Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.
• Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.
• Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.