Object Relational Mapping (ORM)

What is ORM (Object Relational Mapping)?

Before I get to answer this question, I would like to go through what I call a battle that’s raging between the OOAD world and the DBMS world (I am excluding Mainframe databases like Adabas from this fight) when it comes to ways in which you will like to persist/retrieve objects.

People who work with Object Orientated Programming world (like C++, Java, C#, VB.NET) would like to deal with classes, objects and attributes and those who work with DBMS would like to deal with SQL, tables, columns, and stored procedures. There is a valid argument to be made for either group. I have worked on both sides of the aisle and its pretty hard for me to pick sides, and I will not.

I have worked on projects where we all drank the Object world Kool-Aid and designed our database layer to be represented by business entities (remember the EJB 1.X/2.X world, sorry Microsoft you were sleeping then or at least people were not noticing you as you did not have any specifications like Java did) and I have worked on projects where people wrote everything in stored procedures and used the Java/.NET programming languages as a pass through for what was entered in the presentation layer.

A few arguments against the use of stored procedure in database by the object oriented world are listed below

• It’s not portable.
• Why have the business logic in the database.
• It’s not scalable.

A few arguments against the use of business classes to represent entities are listed below

• Transaction management is a pain.
• Performance is poor
• Difficult to understand, SQL is so easy

Here comes ORM, its meeting in the middle. Many frameworks that are built on ORM concept will allow you to map business entities from your business domain model to corresponding relational tables/columns based on standards dictated by the framework you select. There are many frameworks that are available each providing some basic features, a few are listed below

• Transactions
• Object Navigation
• Object caching – you can store least updatable information in application layer cache thereby preventing unnecessary database lookups.
• Provides a clear separation between the business classes and the corresponding tables/columns or stored procedures used to persist the instances (or objects).
• Represent relationship between classes (example one-to-many, many-to-many etc)

ORM Frameworks

Following Frameworks are widely used in the ORM world and more are coming

For java programmers

• Hibernate
• EJB 3.X
• Toplink by Oracle
• iBatis

For .Net programmers

• NHibernate
• ADO.NET Entity Framework
• iBatis for .NET

In the Java world, prior to EJB 3.X specification, EJB 1.X/2.X provided ORM capabilities but to use EJB 1.X/2.X was a real pain, also if not implemented correctly, it resulted in poor system performance. Hibernate started out as a successful attempt to reduce the pains from EJB 1.X/2.X implementation, in fact many projects started dumping EJB 1.X/2.X completely from the picture. Hibernates success is what lead to EJB 3.X specification and if you are familiar with Hibernate then EJB 3.X is a cake walk. I plan to cover Hibernate in another blog.

Microsoft did start out with LINQ, but recently they have come up with ADO.NET Entity Framework. I will speak about that in another blog as I feel it deserves its own blog. If you want to know Hibernate but do not wish to work in Java then use the “NHibernate” project instead although long term goal should be ADO.NET Entity Framework.

Apache’s iBatis is another framework which I would recommend to anyone who has a lot of legacy code in relational database and does not wish to reengineer some of the business code out of the database. Apache provides iBatis libraries for both Java as well as .NET programming platforms. I also plan to cover this framework in another blog.

Why I like ORM

Dealing with business entities like User, Department etc and representing them as classes comes natural to an object oriented programmer. By representing your business entities as classes you can create business domain model using various UML tools (Rational Software Architect, MagicDraw etc) and can get your business domain model understood and revised by the business community. Once that’s done, you can forward engineer the model (obviously you will have to do some touch up) to create skeleton code in Java, C++, C# or VB.NET. You can then pass on the model and the generated code to the development team resulting in productivity improvement.

Writing SQL and stored procedures efficiently results in getting the last ounce of performance from the database. Typically in my experience it’s difficult to get a good developer who understands database and a DBA who understands programming. ORM kind of bridges that gap; you can have your development team work on classes/objects while you can have your DBA help you with getting the best performance out of the database by looking at the SQL that the ORM Framework is generating. I have many times looked at the SQL generated by the ORM framework to ensure that correct indexes are picked and in some cases had to apply tweaks to the configuration files of the ORM framework to ensure the correct SQL gets generated. This activity which I refer to as performance tuning can be independently done without impacting the developers or asking them to change the SQL as there is no embedded SQL that they will be using in their Java/.NET code; the power of ORM Frameworks (more on this in my Hibernate, ADO.NET Entity Framework, iBatis blog)