Nowadays it’s very usual to work with object-oriented programming and relational data bases. Relational data bases are all about tables, relations and groups. However, the object-oriented programming paradigm consists of objects, attributes and inter-object relationships. When these objects need to be stored using a relational data base, it’s very obvious that these two models of representing information are very different from each other. We need some kind of translation to transfer data from one to the other.

If we’re using objects in our application and we want to save them, we’ll probably use some data base system. We’ll most likely establish a connection to the data base, create a SQL sentence with the values of the object (or call some kind of stored procedure), and save them to some table. Easy enough, right? Well, this may seem trivial for a small object with 4 or 5 properties. Just consider an object not so small, with 40 or 50 properties. But… what happens with associations? And… what if the object itself contains some other objects? We’ll store them in the data base as well? All of them or just some? What will we do with foreign keys? We can see that, as the application gets more complex, this translation is not so trivial anymore… As a matter of fact, storing objects in the database can become a very usual source of headaches. There are some studies which state that up to 35% of code is dedicated to the role of translating data between the application and the data warehouse.

And this is where Object-Relational Mapping tools come into play. ORM tools applied to databases transform a DB register to a code object and vice-versa, allowing us to abstract away from writing code to directly access the database. This will speed up development and will allow us to follow the mantra of focusing on business functionalities, not on application plumbing.

But, what exactly can an ORM tool helps us with? Well, they usually do some things like:

• Handle object persistance (to a database, for example). You won’t have to write code for this. And remember, less code means less bugs and less headaches.
• Access different databases. Most of these tools support communicating with different database providers (Oracle, MS SQL Server, MySql, Postgre, etc.).
• Cache. Many of these tools offer some way of caching objects in memory, resulting in much faster data access.
• Help with design. Some of these tools also provide some kind of wizard or graphical interface to aid in the design of the schema and/or database, which leads us to the following point:
• Create your database for you. If you have your data schema already modeled, some of these tools will not only handle how to get the data or how to write it. They can also create the database.

You’re already convinced to use an ORM for your project, right? Good. Now take a look at the most popular ORM tools available for .NET:

• Linq to SQL: not really a full-blown ORM, but it does help with data access.
• NHibernate: I would say NHibernate is one of the most mature ORM projects in .NET, and one of the most used as well.
• Entity Framework: Microsoft’s new kid on the block. Its first version didn’t receive very positive comments, but its latest release looks very good indeed.
• LLBLGen Pro: very mature project, although it’s not the simplest of all.
• DataObjects.Net: quite new, but very promising. It already has a lot of interesting features. Definetely worth taking a look at.

In the next post I’ll be covering Entity Framework a bit. Stay tuned!

Related posts:

1. Things to consider when using Entity Framework
2. Entity Framework
3. Some open source projects for .NET you should take a look at
4. Which database to use for a personal project?
5. Sluggish database view? Materialize it!