In this first blog on "Architectural Dilemmas," I am going to examine object/relational (O/R) mapping. In Part I, I'll provide some background on the subject; in Part II, I'll present some of my opinions on the topic.

IT systems need persistent storage (unless, of course, the systems are really trivial ). This persistent storage usually comes in the form of a relational database, such as Oracle, Microsoft SQL Server, IBM UDB, and the like. There are several alternatives to RDBMSs; for instance, object-oriented databases (OODBs) db4o, persistent object stores (Prevayler, XML databases, and the like.) However, at least until now these alternatives haven't really caught (maybe I'll discuss why on another post) and the fact is that RDBMSs remain pretty much ubiquitous.

Thus you are faced with the task of getting data from the DB into your business logic. Unfortunately the object model and the relational model are somewhat at odds (what Scott Ambler calls "Impedance Mismatch") which means that a properly designed object model will not have a direct automatic map between objects and tables.

The result of that mismatch means that you need to get the data by using one of the following approaches:

• Direct data access; not highly recommended. Retrieve/Save by using SQL calls(either dynamic SQL or a stored procedure) whenever needed by the business logic. The reason this is not recommended is that there is no separation between.
  
• ata Access Layer (DAL). Have an object (per table) that knows how the tables are constructed. The DAL objects retrieves the data. Sometimes this is combined with Data Transfer Objects (objects with only setters/getters to change the data) to transport data between tiers.
  
• ActiveRecord. A class that has the same structure of a table fields. A class instance represents a row in the table and static methods affect the whole table. The class abstracts the SQL needed to actually get to the DB.
  
• O/R Mapping. Have a layer that is responsible to bridge the gap between the "proper" object model and the "proper" database model.
  

There are several variants for each approach and mixes of the approaches; for example, the ActiveRecord implementation in the castle project which builds on Nhibernate, an O/R mapper.

Many implementations (for the various methods) use code generation (there are hundreds of generators you can find many of them ordered by platform at http://www.codegeneration.net). There are implementations that use stored proecdures and there are ones that rely on dynamic SQL. Plus there are few middle-ground approaches like iBatis.

In Part II I will discuss motivations to use O/R mapping (over the other approaches) as well as when not to use O/R mapping.

Want to have your dilemma analyzed? Send your architectural/design dilemmas to ask@rgoarchitects.com.