How Vietnam Can Still Be Won
Imagine the way the world would be if after 9/11 the Americans had not reacted to the attack on their homeland. If they had shrugged their shoulders and allowed an assault on their very soul go unchallenged. A similar thing occurred in the object relational mapping world on 26 June 2006. On this date Ted Neward released an article entitled “The Vietnam of Computer Science” which attacked the credibility and usefulness of object relational mapping. After being attacked, America stood its ground, fought back and she is respected for it. After being attacked the O/RM fraternity went to ground and responded with silence. This seemingly confirmed the validity of Ted’s arguments and damaged the belief that O/RM has a rightful place in computer development.
Understandably the events of 6/26 were less dramatic and life changing than 9/11 and I am in no way implying that Ted is a member of some anti-persistence Jihadist movement (al-Qwerty), but the principle is the same; When someone attacks your core beliefs and credibility the only response, the only way to keep respect, is to defend yourself.
To severely paraphrase Ted’s very lengthy article he transposes the problems of the Vietnam War on to object relational mapping.
“Object relational Mapping…represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy”.
He then goes on to highlight the fundamental problems that he believes make object relational mapping such an unappealing proposition. This article is my response to the misconceptions held about object relational mapping and an attempt to correct the damage done by that article.
The Impedance Mismatch
The impedance mismatch is the difference between the object models interpretation of state and the database schemas storage of state. In some regards Ted has a valid point of O/RMs handling of this point. Most O/RMs are domain modeled and focus on an ODBMS implementation to suit the use of transparent persistence. Unfortunately they then throw in a smattering of methods to cater for translating RDBMS data. If a requirement falls outside of object model persistence their effectiveness as O/RMs becomes as useful as a glass door on a dunny (Aussie word = toilet).
The impedance mismatch is nullified if you can translate data from any data base schema model to any other object model using a simple standard approach. Technology now allows for the O/RM to implement the object model (ODBMS) or database schema (RDBMS) driven design methodology or a combination of the two. This gives latitude to the developer and allows them to decide which part of the of object model to database schema spectrum they choose to use, without any overhead cost or reduction in effectiveness.
As most O/RM’s have focused on domain modeling (ODBMS) this has provided fuel for the fire Ted has lit in the O/RM debate. Flexible O/RM Technology extinguishes the flames of the impedance mismatch and negates the biggest single issue facing O/RM today.
Object to Table Mapping Problems
Ted talks about the deficiency of the three options for object to table mapping: table-per-class, table-per-concrete-class, or table-per-class-family. The argument here is based on the understanding of 1:1 mapping between object and persisted state. This is a valid consideration for an O/RM implementing 1:1 translations using either a ODBMS or RDMBS driven design, but is irrelevant for OR/Ms providing full n:n capabilities. The true n:n O/RM can translate data between any object structures and database schema structures and is not limited to the three simplistic design suggestions above.
Unfortunately Ted missed the marked with his interpretation of n:n mapping, rather confusing it with parent-child data relationships. n:n translations are about sourcing individual pieces of data from different data base tables and moving them into different business objects. In n:n mapping there is a 1:1 relationship between tuples (data rows) across multiple relation variables (tables). A database row having a 1:n relationship with other database rows in other tables infers parent to child relationships, an irrelevant issue when taking about n:n or 1:n translations.
The latest O/RM technology has improved such that you can translate data between n objects to n tables to n data sources.
The Schema Ownership Conflict and Dual Schema Problem
Ted argues that with O/RM’s you often don’t have the ability to determine how the database schema should look. Even where you have a clean slate and you create the database schema to match your object model, eventually with business concerns the schema will be altered from the pure design that originally fitted your model.
The ability of O/RMs to handle n:n mapping makes this topic irrelevant because with n:n mapping, even if you change the schema or move the data base fields, the mapper can source them from any location they are sourced to.
The latest O/RM technology can translate data regardless of schema ownership and object model design. Even if schemas change and if object models change it is simply a matter of changing translation rules.
Entity Identity Issues
Ted’s following three indictments of O/RMs are based on the assumption that they all implement a domain model design. The entity identity issues described in this section are a result of this limited viewpoint. The question asked here is how to identify different objects in memory when the data they are reflecting from the database is identified by primary keys. The supposition is that the memory pointer does not contain enough information about the object to identify it from similar typed objects. Ted also questions how to identify an object in memory where the same data exists multiple times in the relational database and does not contain an identifying key.
These issues, if they can even be called that, are purely design considerations that all systems implementing objects must consider. The fact that these points are used to criticize object relational mappers, even domain model driven ones, shows a lack of understanding of object-oriented design. In properly designed objects, the key that identifies state in the database will be reflected in the key that identifies the object state. If there is a primary key in the database it will almost always be put into the object in memory. This is even true in n:n mapping.
When soldiers go to war they wear dog tags. All tags hold the soldiers name and a unique identifying number to limit issues with soldiers having the exact same name. This identifier is put in all objects in memory for the same reason.
Ted asks: How do you, with database tables where the same data exists without a primary key, identify the objects created from it in memory? The data represented in these tables is non-updateable data therefore the objects in memory are also non-updateable and do not need identification. The only reason you need to identify an object is for the purpose of updating it.
Concurrency and transactional issues brought up by Ted are an application design issue and do not affect the operation of the new O/RM technology. Ted again has focused on the inadequacies of domain-modeled systems. He has failed to realize that there is an alternative to this system and that O/RM technology has leaped forward and overcome these problems.
The Data Retrieval Mechanism
It is implied here that all O/RMs must use three types of approaches for instructions on loading data these being: Query-By-Example (QBE), Query-By-API (QBA), or Query-By-Language (QBL) approaches. This once again is assuming that the O/RM is a domain model driven implementation and relies on some form of intermediate query language. True, if the O/RM relies on an IQL they do suffer from these problems. However these issues are irrelevant for those O/RM’s that support true n:n translation i.e. not domain driven, and full SQL/Procedure querying.
The Partial Object Problem and the Load Time Paradox
“The goal of any O/RM is to enable the developer to see “nothing but objects.””
This flawed assumption is based on Ted’s own version of what an O/RM should be. In actual fact modern O/RMs provide the facility to perform raw data queries for the purpose of drill-down lists and the ability to load objects from preloaded data. O/RMs are now flexible enough to support whatever implementation the developer decides to use.
Vietnam highlighted the failure of our conventional means in defeating an unconventional enemy (I, as an Aussie use the word “our” because we were involved in Vietnam, just like we were involved in Korea, the Gulf War, the War in Iraq, Afghanistan. Hey America, if we ever decide to invade someone, say New Zealand, its your turn to have our backs). The U.S has adapted to this by using smaller, more agile forces that are quickly adaptable to changing circumstances. O/RM technology has also adapted. The focus is now on opening up the concept of O/RM so that it is not limited to the two ends of the object model-database schema spectrum but gives the developer full control of the decisions made in their application development.
For all my disagreement with Ted he has done us all a service by bringing fundamental issues about O/RM to the forefront so we can continue to improve upon them. I hope this article starts the rebuilding process and showcases object relational mapping as a valid and exciting solution to data access and object translation.
GURA Object Director & Data Gate
Last edited by Steven Hughes; 02-20-2008 at 09:47 PM.
By Todd B in forum vb.announcements
Last Post: 05-04-2000, 03:44 AM
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center