The Never-Ending ORM debate and why its a waste of everybodys time
Whether you are in a startup, an established company or just tinkering around, you've probably come across the same question: "How do I get data from my database?" Theres always the "hand-rolled" option, but, once again, I will have to reach into my bag of Eddie-isms and pull out:
Well, now that that is out of the way, lets assume we don't want to waste our time reinventing the wheel and go with an ORM that gets us past the repetitive cruft of getting the data and mapping it manually. Lets follow the process I outlined in my previous blog (The Magic Formula to choosing the right piece of software) and see where the lines take us.
OK, I'm a .NET guy, so that limits our scope to a few products. Lets list out the most popular:
If you want to make an apple pie you can always grab a shovel, a handful of seeds and a big warm pile of horse$@#$ and do it all yourself. Or, you could just go to the store and grab a bunch of apples and start from there.
Well, now that that is out of the way, lets assume we don't want to waste our time reinventing the wheel and go with an ORM that gets us past the repetitive cruft of getting the data and mapping it manually. Lets follow the process I outlined in my previous blog (The Magic Formula to choosing the right piece of software) and see where the lines take us.
OK, I'm a .NET guy, so that limits our scope to a few products. Lets list out the most popular:
A quick look at Google Trends (just as a quick way to see if anyone is talking about them) narrows it down to Dapper, Entity Framework and NHibernate.
Since the others don't really register on here, (I know some of you will complain, but I cant compare what I can't find any information on) I decided that I would just compare these three.
Great, lets see what how each of these three stack up in terms of the following:
Great, lets see what how each of these three stack up in terms of the following:
- Age of the tech: Is this something that's in beta? Is it mature? Have the bugs been stomped out?
- Owner of said tech: Is it one contributor? Is it an active open source product?
- Community/Support: When it breaks, who can help? Do I need to pay? Are there books etc?
- Performance: Is it fast? Is it slow?
- Feature breadth: Does it do one thing well or a bunch of stuff just "OK"?
- Is it widely used: Are people actively using this product?
- How easy is it to use and tune?
Age:
This is an interesting one actually; they have all been around for an eternity (in software years) By 2008 all of them where pretty widely used and discussed on the internet. They are all about a year apart in age, so lets rank them by age, 3, 2, 1 respectively.
Owner:
Hmm... one of them is Microsoft... I'm going to give that the highest marks simply because they've been a large part of paying my bills for the last 15 years. The second most impressive is NHibernate considering the Java and .NET worlds are actively developing this product. Dapper was built by the Stack Exchange guys, and they haven't been taking in a lot of pull requests from others..Im going to have to rank 5,3,1 respectively because the margins are a bit wider than the previous metric
Community/Support + Is it widely used:
I usually like to look at the number of downloads of their packages to see how widely used each one is. This can, most of the time, indicate the level of support something gets. If you have a handful of people, and they have issues that aren't addressed, they will stop using it. EF had 19,608,418 at the time of writing this article, NHibernate had 1,427,351 and Dapper 1,613,228. So, 10, 3,5 respectively because those numbers are insane, and just like Shakira's hips, they do not lie
Performance:
So this is near and dear to my heart, and where most people cook their tests. (see this forum) and even the original article indicates that dapper is marginally faster than EF in the simple cases, but crashes and burns with more complex scenarios (read real-world)
So, how do we objectively score this? Most of the ORM users out there will blatantly abuse its power and end up with horrific performance, which would then indicate that you should probably stay with a Micro-ORM that forces you to do everything yourself. I dont like that either, if you have the knowledge to do it "right" using a Micro-ORM, you can do it right in an ORM and get the same performance.
With that said, I need more thought for this rank, so, I will omit it until we finish the scoring and see if its a key metric after all is said and done.
Feature Breadth:
The word "micro" in front of Dapper pretty much tells you what this does; one thing... so it gets a 1. A quick internet comparison between EF6 and Nhibernate 4 features shows us they are close, but EF6 takes the lead with several awesome features. So, 10 to EF, 7 to NHibernate it is!
How easy is it to use and tune:
Aaaahhh... this is another point of contention for people. A lot of people argue that dapper is drop dead simple to use. WRONG! try paging or mapping more than one child record. Im giving them a 0, because you have to know SQL ... and well... and you wont be able to run the same type of query against different stores (read SQL server, Oracle and MySQL).. even if you end up using stored procs for everything (and if you do, 1998 called and said that you need to hurry because the Denny's early bird dinner is over at 4 pm) you still need to know how to do all the complexities needed in a data access layer. Ok, so the only real contenders are EF and NHibernate. They are both pretty simple to use if you know how to write code, but the latter gets hairy with projects and dynamic objects (read select a,b,c from table Y into an anonymous object) ... so 10 to EF, 8 to NHibernate.
Ok... it's time to maths now and see where we are at with the numbers.
EF : 1+5+10+p+10+10 = 26+p
Great, so even without the performance numbers (represented here by p) we can see quite a lead by EF over the other two. So, for me, if I am ever going to consider writing DAL code, I would, without hesitation, bet on EF.
Now, if you've read this far, thank you for following, but I'm sure you're asking about the p variable;
Well, I'm glad you asked (even though you were yelling and thats rude..) but you shouldn't take performance into consideration until you know exactly what you are trying to improve on; never prematurely optimize something until you know what it the problem is to begin with. Furthermore, if you are performance conscience, are you sure the time lost to hand-rolling everything will be worth the performance improvement? The way I see it, build your application first and then fix the problem parts; until its 'working' you don't know if its slow. At that point, you can substitute out that are with a Micro-ORM and get the tuning you need. I'm going to steal a quote to illustrate something here: "You can use the back of your screw driver as a hammer, but its probably easier to grab a hammer" Basically, you can strategically use a Micro-ORM for the parts of your system that need optimization, but you would be doing yourself and your organization a disservice by choosing a Micro-ORM for your DAL.
And based on this article, it seems that you would be doing a similar, albeit less severe of, a disservice if you do not choose Entity Framework.
Disclaimer : Despite rumor, I am not on the Microsoft payroll.. but I you can hook that up, please let me know :)
This is an interesting one actually; they have all been around for an eternity (in software years) By 2008 all of them where pretty widely used and discussed on the internet. They are all about a year apart in age, so lets rank them by age, 3, 2, 1 respectively.
Owner:
Hmm... one of them is Microsoft... I'm going to give that the highest marks simply because they've been a large part of paying my bills for the last 15 years. The second most impressive is NHibernate considering the Java and .NET worlds are actively developing this product. Dapper was built by the Stack Exchange guys, and they haven't been taking in a lot of pull requests from others..Im going to have to rank 5,3,1 respectively because the margins are a bit wider than the previous metric
Community/Support + Is it widely used:
I usually like to look at the number of downloads of their packages to see how widely used each one is. This can, most of the time, indicate the level of support something gets. If you have a handful of people, and they have issues that aren't addressed, they will stop using it. EF had 19,608,418 at the time of writing this article, NHibernate had 1,427,351 and Dapper 1,613,228. So, 10, 3,5 respectively because those numbers are insane, and just like Shakira's hips, they do not lie
Performance:
So this is near and dear to my heart, and where most people cook their tests. (see this forum) and even the original article indicates that dapper is marginally faster than EF in the simple cases, but crashes and burns with more complex scenarios (read real-world)
So, how do we objectively score this? Most of the ORM users out there will blatantly abuse its power and end up with horrific performance, which would then indicate that you should probably stay with a Micro-ORM that forces you to do everything yourself. I dont like that either, if you have the knowledge to do it "right" using a Micro-ORM, you can do it right in an ORM and get the same performance.
With that said, I need more thought for this rank, so, I will omit it until we finish the scoring and see if its a key metric after all is said and done.
Feature Breadth:
The word "micro" in front of Dapper pretty much tells you what this does; one thing... so it gets a 1. A quick internet comparison between EF6 and Nhibernate 4 features shows us they are close, but EF6 takes the lead with several awesome features. So, 10 to EF, 7 to NHibernate it is!
How easy is it to use and tune:
Aaaahhh... this is another point of contention for people. A lot of people argue that dapper is drop dead simple to use. WRONG! try paging or mapping more than one child record. Im giving them a 0, because you have to know SQL ... and well... and you wont be able to run the same type of query against different stores (read SQL server, Oracle and MySQL).. even if you end up using stored procs for everything (and if you do, 1998 called and said that you need to hurry because the Denny's early bird dinner is over at 4 pm) you still need to know how to do all the complexities needed in a data access layer. Ok, so the only real contenders are EF and NHibernate. They are both pretty simple to use if you know how to write code, but the latter gets hairy with projects and dynamic objects (read select a,b,c from table Y into an anonymous object) ... so 10 to EF, 8 to NHibernate.
Ok... it's time to maths now and see where we are at with the numbers.
EF : 1+5+10+p+10+10 = 26+p
NHibernate: 3+3+3 +p+7 +8 = 16+p
Dapper : 2+1+5 +p+1 +0 = 9 +p
Great, so even without the performance numbers (represented here by p) we can see quite a lead by EF over the other two. So, for me, if I am ever going to consider writing DAL code, I would, without hesitation, bet on EF.Now, if you've read this far, thank you for following, but I'm sure you're asking about the p variable;
How are we not taking PERFORMANCE into consideration?!
Well, I'm glad you asked (even though you were yelling and thats rude..) but you shouldn't take performance into consideration until you know exactly what you are trying to improve on; never prematurely optimize something until you know what it the problem is to begin with. Furthermore, if you are performance conscience, are you sure the time lost to hand-rolling everything will be worth the performance improvement? The way I see it, build your application first and then fix the problem parts; until its 'working' you don't know if its slow. At that point, you can substitute out that are with a Micro-ORM and get the tuning you need. I'm going to steal a quote to illustrate something here: "You can use the back of your screw driver as a hammer, but its probably easier to grab a hammer" Basically, you can strategically use a Micro-ORM for the parts of your system that need optimization, but you would be doing yourself and your organization a disservice by choosing a Micro-ORM for your DAL.
And based on this article, it seems that you would be doing a similar, albeit less severe of, a disservice if you do not choose Entity Framework.
Disclaimer : Despite rumor, I am not on the Microsoft payroll.. but I you can hook that up, please let me know :)
Comments