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.