Okay, I wasn't planning on having a Part IV of my series on "Architecture Dilemmas:O/R Mapping." (Part I, Part II, and Part III are available here. In addition, a single PDF file is also available.)

What prompted Part IV was my reading Ted Neward's blog on why he thinks O/R mapping is The Vietnam Of Computer Science. If you manage to read over the Vietnam history, Ted makes some interesting point on the problems of O/R Mapping. I tend to agree with most of them; in fact, I mentioned most of them as well (though maybe not as eloquently). It is also interesting in the light that I spent about two hours yesterday debating some of these issues in a meeting with several other architects.

Toward the end of the article Ted offers the following solutions:

1. Abandonment.
2. Wholehearted acceptance. (move to an OODBMS)
3. Manual mapping. (write code by hand - iBATis would fall here as well)
4. Acceptance of O/R-M limitations. get the X% (50%,80% whatever) you can get out of O/R mapping
5. Integration of relational concepts into the languages. (e.g. LinQ)
6. Integration of relational concepts into frameworks. (embedded data-rows/data sets etc in classes to hold data, use typed data sets as well)

Ted recommends going with solution #1 or in his words "...Worse, it is a quagmire that is simply too attractive to pass up, a Siren song that continues to draw development teams from all sizes of corporations (including those at Microsoft, IBM, Oracle, and Sun, to name a few) against the rocks, with spectacular results. Lash yourself to the mast if you wish to hear the song, but let the sailors row."

The way I see it "Computer Science" now has more than 10 years of experience with O/R mapping technologies and the limitations of O/R mapping are well noted. In fact, the good O/R mappers "Accept O/R limitations" (#4 above) and provide mechanisms to by go directly at the data or provide hints for the database etc. And as I said in Part III there are situations where O/R mapping is not the best fit (e.g. reporting), but as someone at the meeting yesterday said, if you have serious reporting needs you would probably have a separate database (e.g. Datamart) just for that.

I think Ted is too quick to forgo the savings of O/R mapping (those X percentile of code you don't need to write, the fact that you externalize the data model from your code etc.) and the fact that for many problems (yes, these are "just" the simple ones, but how many times all of y our application is complicated) O/R mapping will be sufficiently good out of the box--which is,by the way, exactly why tools like Rails are getting so popular. We don't need or want to write this rote code over and over again.

I still think that if you don't expect O/R mapping to be a silver bullet which will absolve you of all your database pains--O/R mapping provides you with a good balance between benefits and costs.

Posted by Arnon Rotem-Gal-Oz at 12:12 AM  Permalink | Comments

This is the last part of a three part series on O/R mapping. Part I provided some background on the subject. Part II described the benefits of O/R mapping and analyzed some of the costs of using O/R mapping. Part III (this post) provides my opinion and some guidance.

O/R mapping is not a panacea, as was shown in the previous post. Using O/R mapping incurs several costs (which are sometimes hidden at first glance). Nevertheless, using O/R mapping provides a good balance between the need to bridge the gap between an OO model and a relational one versus the time and effort needed to provide that bridge. O/R mapping is especially useful if you are also following Domain Driven Design principles which support a rich and meaningful (domain) object model.

Several years ago (good) O/R mappers were hard to find. The first real O/R mapper I used was TopLink (now Oracle Toplink)--indeed the Java world seems to be leading the adoption of O/R mapping into mainstream programming. Now there's Hibernate (which is rather popular), JDO (I think the first O/R mapping standard), and now the Java Persistence API as part of EJB 3.0.

On the .Net side there's a wide range of solutions, starting with NHibernate (the .Net version of Hibernate) and many commercial and open source solutions. Microsoft is following this trend and will be introducing two new O/R mapping frameworks: LinQ for SQL (formerly known as "DLinQ") and LinQ for Entities (built above ADO.NET entity framework).

When a solution has mostly with data-entry screens or simple CRUD operations, a viable option is to use the ActiveRecord pattern. ActiveRecord is basically a simplistic O/R mapping (actually it can be considered as an R/O mapping as it is the table row that is the mapped to an object). While ActiveRecord provides an anemic domain model it can still be useful in the scenario mentioned above. The added benefit of ActiveRecord mapping is that it is simple to generate this kind of mapping automatically (e.g. what Rails or MonoRail do).

DAL (Data Access Layer) or direct data access are a good options when the solution is very data centric and/or database intensive. A classic example for this would be a reporting application. iBAT is is a variant on the DAL theme (I consider it an XML-based DAL). The good news is that the SQL is externalized from the code and can be tweaked and updated independently. The downside include lacking documentation as a lot of mapping files (mapping per query/SQL statement).

Lastly, on smaller projects which are not very data intensive, you can also consider using an object-oriented database (such as Versant FastObjects, Objectivity, or db4O). While I wouldn't use them to create the next version of the NYSE data center, they can make life very easy where the data requirements are modest.

There are many ways to get to the data from the object model. Each approach has it place and sometimes it is worthwhile using more than one in a project. Whatever approach you take. I believe it is a good practice to consider utilizing the Hexagonal architecture principle and keep the objects clean from the data access code (POJO/POCO).