Going to Vietnam Because of ORM

In my previous post I have talked about ORM. But believe me, if you don't use things wisely you are going to fall like anything. In this article I am not going to write any code but still it is a pure technical article. I will talk about enterprise applications and how quickly love for ORM will drag you to the black hole.

Around two years back, at the time when .Net 3.5 arrived, I was reading a chapter from a book. It is from Oreilly in which the author states that your DBA's job is in danger—we have LINQ to SQL, an easy way to do the task. And trust me, I just like this statement. I am not a DB guy, and I don't like much to mess with databases. But as I learned more, I understood the importance of Database guys and databases. And personally I found a person like Chintak Chappia who is not only good with databases but also a friend, philosopher, and guide. I definitely don't want to piss him off by my simple LINQ queries which eventually generate complex SQL queries. Don't trust me—here is the example.

Now, take a hypothetical example: a very big application. This application has around 1000+ tables and 35+ modules to handle. Ya, very big application it is. And the first and foremost mistake done by programmers is to add an edmx file for the entire database. (Here I am taking the example of EF only, but this is true for all other ORMs too.)

It may seem lame but it is true. A single file which has all the details of the database and relationships. And the first effect of this is that the file's designer view will crash. Now, every now and then you have to open the XML file and edit it manually. And a single change in the database will cause 2 to 3 hours to get effects in that file. And every time you invoke that file in your program it will take that much load to compile and run.

There are a few workarounds to this. Use multiple edmx files. Maybe one file per module. The pros are that you have the mighty designer of the edmx file and it is lightweight. The cons are that the database guy has to manage more than one edmx file. But I don't think that will be a big problem as it saves much time.

Another common mistake is using default options. Big ORMs come with multiple options. Entity Framework and NHibernate are two of the big and classic ORMs. They have plenty of options to load and save data. Like NHibernate has a "save all" type option. This allows you to save data at a specific point in time. This will increase performance as you don't have to go back and forth to the database.

Okay, if I am taking care of the number of tables per edmx file and also take care with saving and loading options, my life will be saved. The answer is Yes and No.

Yes, if your application is a single-user oriented application. Like some applications such as news sites. Where a few people are adding data and many are reading data. Now, with the course of time, data start coming from cache, and it will use the caching mechanism of your application. Because of this, the application runs like a charm. In this type of application you can use ORM, this will increase productivity without hurting you much.

No, now if you are making the next Facebook or my favorite site Stackoverflow. Where there are tons of people reading data and tons of people adding data. There you will face problems with ORM.

Why???

The answer lies just in front of you. A computer is basically a dumb machine. It does exactly what you tell it to do. It doesn't know where and when it should change its behavior. Now, any ORM generates SQL queries based on some logic. And trust me, these queries are weird like anything. If you add a few joins to an entity, it will add a few more joins to the query and that makes the query more complex—not only to debug but also for the database server to process. And this will affect the performance of the database server as well as your application.

And the best thing is, whatever time you have saved by using ORM, you will have to give more than double the time to just fine-tuning it and also finding out which queries are burning the database server. If you have a dedicated database engineer, then he definitely is going to kill you for burning his server.

So, I can say this is like a nuclear missile which everyone should use wisely. One mistake CAN make a big hole in your application. I am a fan of ORM as a concept, and as a tool I like to use it. But I am so rigid when it comes to the performance of applications or code developed by me. I don't like to compromise with the performance and scalability of my code, and maybe that's why most of the time ORM stays in some of the demo applications I developed just to experiment with things other than ORM and my resume. I know Entity Framework, NHibernate, a little bit of Sub Sonic, and a few others, but I don't like to use them.

I CAN but I avoid!!!