Dapper: The Conclusion

Over the last few weeks, I've taken an existing Entity Framework solution, Nerd Dinner, and converted it to use Dapper. Below is my experience of using Dapper and my opinion on whether it is suitable over Entity Framework to use in projects.

The final version of Dapper Dinner can be found here. The project has gone through a number of iterations to get to its current state. The first version was a simple replacement of the Entity Framework repository with a Dapper one. The second was the introduction of a richer repository layer and more efficient queries, and the final version was adding the ability to manage object state. As you can see the final project is quite different from the original Nerd Dinner code.

Learning

Dapper is a relatively easy framework to learn, especially if you're fluent in SQL. The Dapper homepage is a place in learning how to use the features of Dapper. Also Sam Saffron (the creator of Dapper) has done a number of blog posts on the subject that are incredibly helpful. Additionally StackOverflow already has plenty of questions and answers on the subject.

The greatest challenge in implementing this solution was the SQL; it takes me back to "the good old days" of ADO.NET and before. I think the fact that it took me a couple of goes at the paging SQL proves I've spent too long in the Entity Framework world and let my SQL skills go!

Other than the SQL, Dapper is a fantastic framework to work with. Having the SQL statements within the code does mean some of the elegance is lost, and it can look a little unwieldy, especially when compared next to Linq, but it gives you full control over the SQL produced.

Nerd Dinner vs. Dapper Dinner

The query on the Nerd Dinner homepage returns the top 8 upcoming Dinners with the most RSVP's, the SQL Entity Framework produces for this is:

This is clearly a lot of SQL for such a simple query; compare this to the SQL the Dapper Dinner produces:

As you can see the SQL is much simpler. This is the beauty of Dapper it gives you direct control of your SQL.

Conclusion

So what do I think of Dapper?

To me, Dapper gives control of the SQL back to the coder. With Entity Framework and Linq it is far too easy to make complex and slow calls to the database without even realising, this in turn can and will make you applications complex and slow. Dapper takes this complexity away. In my opinion, Dapper makes me think "What do I need from the database?", it stops me returning unnecessary data from the database and makes me think about the flow of the application more.

Do I miss the ease of using Linq?

Part of me does (because its easy), but the programmer side of me is glad its gone because it makes me think, and it makes me design my repository layer in a responsible manor.

Do I miss the lazy loading of Entity Framework?

Not in the slightest, I think that lazy loading can be one of the most abused features of Entity Framework, with people not realising the number of extra calls being made to the database.

Would I use it in a real world situation?

Absolutely, when starting my next project I will give serious consideration to using Dapper (or another micro ORM) as it just gives so much control back to the developer. It has all the power of working in ADO.NET without any of the pains of mapping results to object.

For any application performance is key, it is no good worrying about performance once the application is complete - it should be considered from the start. Dapper is one of the first steps you can take in order to get the performance you want.