.Net Applications with ORMs

Now-a-days all web applications make use of a good ORM framework. During the early days of coding, we used simple ADO.NET by using classes such as SqlCommand, SqlDataReader, SqlDataAdapter, and DataSet. As days went by, ORMs took the lead and programmers preferred to use them instead of plain old ADO.NET.

With ASP.NET, the ORMs that are commonly used are:

– ADO.NET Entity Framework
– LINQ to SQL
– NHibernate

There are also a few others like Dapper and Massive and the Enterprise Library Data Access Application Block.

When it comes to making a choice between Entity Framework and NHibernate, majority of the developers prefer Entity Framework, because it is a Microsoft product and it comes bundled in the IDE. Being a .Net developer, I too would agree with the majority of the team that Entity Framework would be my first choice. But the first ORM that I used was NHibernate.

The first project that I worked on had the map files written using NFluent NHibernate. I admit, it was difficult to create the classes, especially for associations (many-to-one, one-to-many and many-to-many). But it was fun to learn. Once we came across an issue where the application would stop working, due to overflow exception. It took us days to figure out the issue. Luckily we had a tool ‘NHibernate Profiler’, it pointed out a mistake in one of the classes, where the association was wrongly written. And that bug came to light after about 1000 records were inserted.  Earlier as the data was less and it had no primary key/foreign key conflicts, it ran smoothly. But later as the data increased, problems started causing deadlock with associations.

The second project that I worked on, also used NHibernate. But it used the hbm files in xml and not the NFluent one. So it was much easier. And the best part was that – that client had purchased the tool ‘CodeSmith Generator’. All we had to give as input was the DB and it generated the manager files, the hbm files, on the fly. This saved us a lot of time and effort to create the mapping files. But of course, it had the cost associated with it.

Well, if we compare NHibernate with Entity Framework, the latter is much simpler. It was introduced in Microsoft .NET 3.5 Service Pack 1. The edmx file is generated for us. All this comes within the .NET Framework. So it is free and compatible and the learning curve is not steep at all. Entity Framework works well with MSSql. For other databases, connectors are required. Using NHibernate, we can fire multiple queries at one time, which is not the same in Entity Framework. But NHibernate takes a longer time to initialize compared to Entity Framework. That is the only drawback, other than the learning curve.

Both are good in their own way and better than traditional ADO.NET as they do reduce the lines of code to a great extent.

Severina D’Souza