Object Relational Mapping
June 4th, 2011
ORM (Object Relational Mapping) systems are useful in getting you started with a project. They help you to quickly create objects that model your Data Source, letting you interact with the data in a simple and intuative manner.
While ORM is extremely useful, especially in smaller projects, this usefulness comes at a price. ORM becomes a problem in long-term maintenance as you are committed to the ORM you initially select, whether its LINQ, SubSonic, NHibernate, or any other ORM Software Factory system that generates class based on the targeted data source you will need to select one and, in most cases, will be married to it throughout the development (and product) life cycle.
While this may not seem to be a deal breaker it is not until later, during the longer-term maintenance phase, that the price is paid. Developers who inherit the project from you will be forced to continue to use the ORM you selected, even if its no longer available. And if the ORM system is open-source, with its source code available for you to modify, upgrades (or downgrades) to a different version can cause major headaches which often result in the development team refusing to make changes to the ORM for fear of crashing the application (or even worse would be to cause lots of runtime errors that are only discovered after the upgrade).
Another disadvantage is that if the data source schema is changed the application is not shielded from the change. The relational schema of the data is hard coded into the application via the generated classes. If the data model changes the ORM object won’t know until they are regenerated by the ORM software.
The moral of this story is to use caution when working with ORM systems. Anticipating and addressing these kinds of issues beforehand can help to avoid having your hands tied later down the line.