Object-Relational Mapping Systems Encapsulate Change

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.

Comments

• Anonymous
  February 20, 2004
  Do you have a background in ORM, ie did you study it in school? Or did you have previous experince in ORM from another project or a previous employer? How does Microsoft choose which people to hire/assign to different projects? I am curious.
• Anonymous
  February 23, 2004
  Nate,
  
  I never studied ORM in school. The closest thing to it was a regular database class where I studied data modeling, the SQL language, B-tree, and things like that. Before being hired on the Entity Persistence team, I worked as a tool developer for the Performance Lab in Microsoft Business Solutions. There I wrote ASP front-ends backed by databases which is where I learned most of my database knowledge. During that time I also received my Microsoft Certified Database Administrator certification. All that experience led me to be hired on the Entity Persistence team.