Object-Relational Mapping (ORM) Frameworks–knowing the price tags!

I own Telerik’s OpenAccess ORM, I have consulted professionally on Microsoft Entity Framework, this week I had a long conversation with senior types on Hibernate issues. My experience with ORM or ORM-like implementations, go back to 2001, when I was joined Vision Compass and had to immediately investigate and fix major performance problems. While the C++/SQL Server application was not generated by a ORM tool, the design followed what a ORM tool would produce.

 

Wikipedia wise, it has been described as

“(ORM) is a programming technique for converting data between incompatible type systems in relational databases and object-oriented programming languages. This creates, in effect, a "virtual object database," which can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.”

Humanware wise: the lack of availability of skilled database people (as well as communication issues between OOP types and RDBMS types) has resulted in a naïve layering of a database with templates on how to access the data. For many systems, this is sufficient to get the system built and released. The OOP types move on to their next project with a “success” notched on their belts.

 

I said “for many”, the problem is that for high load systems (relative to hardware supporting it) the side effect may be 4 to 10 times more hardware expense then needed if a good database person was involved that knows their stuff.  Often, when scaling issues arrived, techniques like sharding will remove blockage and contention issues. While sharding allows better scaling, it can also make it more difficult/time consuming to build reporting or investigative components on the system.

 

Other issues can arrive when one database is shared by multiple applications, each with their own versioned ORM. While these can be reduces by moving the ORM into a common library that is shared by all of the applications, the problem remains of having to retest all of the applications with each ORM drop; and then, potentially having to update all of the live applications concurrently. If one has to be rolled back, then all may need to be rolled back.

 

The real cost of the ORM is that much of the internal business logic that would be in triggers and stored procedures is moved to higher levels with the result that the core data may become very corrupted in some circumstances. There is no longer a moat and high walls around the cities, instead, the walls are torn down so every street runs into the country side.  It is much easier for a thief to make a living; or a vandal to paint bomb store fronts. In one case, the city is much more secure and safe but commerce may suffer from having to go through a few guarded gates; in the other case, commerce may thrive but then every merchant may have to hire their own guards.

 

The real question is what happened when an enemy comes knocking (corporate espionage, spying), if the city is wide open then the pickings are good, a troop of raiders can ride in and carry out much easily. If the city is gated and guarded, success is much less likely.

 

Just like outsourcing and offshoring seemed like a good idea 15 years ago because it appeared to save money, the trend is increasing to on-shore or repatriate work. ORM saves money and reduce the time to delivery – just like offshoring promised. When you look at long life, evolving systems that keep adding applications, the maintenance costs and complexities start to multiple. You can pay upfront or down the road (or discard the system in 4 years and build your next short lived implementation).