Ted Neward posted a critical article regarding O/R Mapping Tools. He states: "Object-relational technologies are the Vietnam of the Computer Science industry."
Is this why Microsoft slipped ObjectSpaces from Whidbey to WinFS? If not even Microsoft can get it right, do you seriously think the little ISV next door can? On the other side, Hibernate seems to do a good job on that (although I have not tried it in detail yet), and I have also applied Container-Managed Entity EJBs under certain scenarios in some J2EE projects, which just worked fine.
Still it seems that projects using O/R often harvest far more problems than benefits. Especially those that follow an undifferentiated 100% O/R approach. Might it be that people listen too much to pied piper consultants? Or even worse, some think they must implement their own O/R Mapping Layer. Don't burn your fingers, this is by no means at all a trivial task.
The following quote from Ted's article sounds like the accurate summary of a real project I know of (luckily, I have only been watching it from the outside):
Both major software vendors and project teams (building their own O-R layer) fall into the same trap. With object-relational technologies, products begin by flirting with simple mappings: single class to single table, building simple Proxies that do some Lazy Loading, and so on. "Advisers" are sent in to the various project teams that use the initial O-R layer, but before long, those "advisers" are engaging in front-line coding, wrestling with ways to bring object inheritance to the relational database.
By the time of the big demo, despite there being numerous hints that people within the project team are concerned, project management openly welcomes the technology, praising productivity gains and citing all sorts of statistics about how wonderful things are going, including "lines of code" saved, how we were writing far more useful code than bugs. Behind the scenes, however, project management is furious at the problems and workarounds that have arisen, and frantically try every avenue they can find to find a way out: consultants, more developers, massive code reviews, propping up the existing infrastructure by throwing more resources at it, even supporting then toppling different vendors' products as a means of solving the problem.
Nothing offers the solution the team needs, though: success, a future migration path, or at the very least, a way out preserving the existing investment. Numerous "surprises" (such as the N+1 query problem thanks to lazy-loading proxies or massive bandwidth consumption thanks to eager-loading policies) make the situation more critical.
Finally, under new management (who promise to fix the situation and then begin by immediately looking to use the technology in other projects), the team seizes on a pretext, ship the code and hand it off to system administrators to deploy, and bring the developers home to a different project. Not a year later, the project is cancelled and pulled from the servers, the project's defeat complete in all but name.
