From The Depths : Object-Relational Mapping

Metadata Mapping in O-R Mapping Technology

mthalman — Wed, 25 Feb 2004 23:02:00 GMT

In my previous post I described the benefits of using Object-Relational Mapping (O-R Mapping) technology in regards to the encapsulation of change. In this post and several subsequent posts I'm going to delve into some of the basic designs used in O-R Mapping technology. The first deals with the actual mechanism of mapping objects to relational tables and object fields to table columns. Most commercial O-R Mapping products use metadata mapping as the mechanism that describes the relationship between an object and its data source so this is what I will focus on in this post.

Metadata mapping involves a developer defining mappings between an object and its data source in some static form separate from the code which processes that metadata to produce CRUD operations. The form in which this metadata can be stored could be XML, a database, or even directly within source code. The inherent hierarchical structure and non-compiled nature of XML lends itself to be the most useful of these forms. A convenient method of using XML is to create your mappings through source code using a set of APIs which creates a map object of the same type that is used by the system which consumes the metadata. The object is serialized to XML when creating the mappings then deserialized by the system when it needs to read the XML.

The more functionality supported by the O-R Mapping technology, the more complex the metadata mapping structure. For example, if the O-R Mapping technology supports inheritance in its objects, there needs to be a way to express the inheritance in the metadata mapping. Obviously, commercial O-R Mapping products aim to have significant functionality causing the metadata mapping to be quite complex. Because of this mapping tools are developed to generate these metadata mappings. This allows the developer to work through a UI rather than manipulating whichever underlying form was chosen for the metadata mapping.

Mapping is one of the first things focused on when developing an O-R Mapping product. The information contained in the metadata will most likely change over time during development as more edge cases are found. It is important to focus on developing a robust design in the metadata as a lot of change occurring in this area causes churn due to alterations of the old mappings in order to reflect the new design.

In my next post I will describe the different methods of mapping inheritance hierarchies in a relational data source.

Final thought:
You are only as good as your metadata.

Object-Relational Mapping Systems Encapsulate Change

mthalman — Fri, 20 Feb 2004 23:02:00 GMT

Why have an object-relational mapping (ORM) system? Because change happens. There's no getting around it. I'll concede that ORM would not be necessary if you built a piece of software or data source which never had to be updated, extended, customized, upgraded, or have a new technology adopted. Such a piece of software, of course, wouldn't last too long.

At its core, ORM is a separation of concerns in relation to the application that uses it. The application programmer need only be concerned with objects while the ORM is concerned with how the objects relate to the data source. I'd like to go through each of the points raised above and explain how an object-relational mapping system solves these issues.

Updating

ORM encapsulates changes in the data source. In order to improve data source performance, a developer may wish to consolidate the sources of a particular inheritance hierarchy into one source. (I'll deal with the different ways of mapping a class inheritance hierarchy to data source in a later post.) This change can be made within the ORM without effecting the code or functionality of the application whatsoever.

Extending/Customizing

I view extending functionality to be an internal practice and customizing functionality to be a practice done externally. Essentially, ORM effects them in the same way by isolating the changes that need to be made. Of course, enabling external customization has some extra infrastructure involved, but this is separate from the discussion of ORM. Classes can be added to an existing inheritance hierarchy without effecting existing application code.

Upgrading

Upgrading to a new version of a data source has the potential for breaking changes to occur. By encapsulating the communication with the data source in ORM, the breaking changes will not spread to application code.

New Technology

New features in a data source can be utilized more effectively by hiding their interfaces from application code with ORM. For example, the next version of SQL Server, code-named “Yukon”, allows you to use CLR-defined objects in SQL Server through enhanced functionality of UDTs. The new syntax used to manipulate these UDTs can be completely hidden with ORM and never exposed to application code. This allows modifications to be made by ORM developers without impacting higher layers.

It can be seen that ORM encapsulates the change that occurs when dealing with such a dynamic system as the data source.