Use Dapper!! ts the Faaastesssst...and Bestestssss, AAAhhh!! Fastest Micro-ORM in the world! LINQ2SQL Must Die!!!!
Dapper is used on Stack Exchange to deliver extremely fast dynamic content. And it works, Everybody is impressed, me too, no doubt of that. Well Done!! :)
But, what if a team is using using LINQ-2-SQL to rapidly create classes, with drag and drop, enforce linking, built in sanitization, and best of all allow for lazy loading. Well I did a quick test..
We had a challenge at work to optimize an Admin interface, because it took 6 - 10 seconds to load. After identifying the problem and fixing it within 3 minutes and 16 seconds i spent the next 4 hours trying dapper out.
Our Views (MVC.NET) rely on foreign key linking and lazy loading data, and as you know these cost extra connection times to DB's and some of these are Stored Procedure too. Now I realise in order for Dapper to fully shine we would have to rewrite the entire project around POCO - But that means we need to write our own linking mechanisms, check data, sanitization, garbage collection, etc etc.. That just sounds like the times of Classic ASP.NET- Tech from yesteryear which really deserves to burn and wiped off the face of this universe! *cough*
I wrapped dapper around some of the most used calls on orders history table. The result was that simple entities loaded 5 times faster(not displayed here) but the SPROC loaded 5 times slower.(5-5=0)? But, In the background, it also took me 5 times more code lines to achieve this. Less code = less problems- Dapper needs more code lines to work. Dont get me wrong, tt is very impressive though! 8.7% DB its and 700ms Server load time. Nice!
You might be an adamant Dapper user and scratching your eyeballs out by reading this article. I am not slagging Dapper off. I think its amazingly fast, but remember its a Micro ORM and this one was specifically designed for Data Speed over Usability - And is not good for Rapid Development like MVC.NET is meant for.
Linq-2-Sql and Entity might be that fraction slower in database queries but it has all these amazing features, that when taken away from you, you will start to scratch your eyeballs out because you cannot do lazy loading and need to write a zillion lines of SQL, and classes, and all that other stuff... etc.. :)
But, what if a team is using using LINQ-2-SQL to rapidly create classes, with drag and drop, enforce linking, built in sanitization, and best of all allow for lazy loading. Well I did a quick test..
We had a challenge at work to optimize an Admin interface, because it took 6 - 10 seconds to load. After identifying the problem and fixing it within 3 minutes and 16 seconds i spent the next 4 hours trying dapper out.
Our Views (MVC.NET) rely on foreign key linking and lazy loading data, and as you know these cost extra connection times to DB's and some of these are Stored Procedure too. Now I realise in order for Dapper to fully shine we would have to rewrite the entire project around POCO - But that means we need to write our own linking mechanisms, check data, sanitization, garbage collection, etc etc.. That just sounds like the times of Classic ASP.NET- Tech from yesteryear which really deserves to burn and wiped off the face of this universe! *cough*
I wrapped dapper around some of the most used calls on orders history table. The result was that simple entities loaded 5 times faster(not displayed here) but the SPROC loaded 5 times slower.(5-5=0)? But, In the background, it also took me 5 times more code lines to achieve this. Less code = less problems- Dapper needs more code lines to work. Dont get me wrong, tt is very impressive though! 8.7% DB its and 700ms Server load time. Nice!
The next image shows the original linq queries and lazy loading that we used to extract extra information from foreign entities.
Really easy to read in the code, there is no way to mix up ID's in SQL, they are already all linked up as it all links in the background and you chain as much as you like. The result of this though, is 30% Data hits... much, much, more data hits but for far less code! (less code = less bugs)
But essentially, it only took 140ms longer to load. We can't even notice that in an eyeblink. But! What I can assure you is that using LINQ-2-SQL saved us hours of coding, and for a small company like this, 1 hours times several people salaries will never justify 140ms faster loading.
You might be an adamant Dapper user and scratching your eyeballs out by reading this article. I am not slagging Dapper off. I think its amazingly fast, but remember its a Micro ORM and this one was specifically designed for Data Speed over Usability - And is not good for Rapid Development like MVC.NET is meant for.
Linq-2-Sql and Entity might be that fraction slower in database queries but it has all these amazing features, that when taken away from you, you will start to scratch your eyeballs out because you cannot do lazy loading and need to write a zillion lines of SQL, and classes, and all that other stuff... etc.. :)
End of the Day- Its personal preference.
I think Both Stack Exchange and Microsoft have done a great job of these products.
But I'm sticking with Linq 2 SQL :P
Comments