The Case for Speed, Simplicity and Ease of Maintenance
Microsoft’s data access method of choice is Entity Framework. I disagree with that choice. Obviously there are a ton of really smart people who design and build Entity Framework. There are also fellow Microsoft MVPs who I realy respect like Julie Lerman who spend a ton of time evangelizing Entity Framework. So it does seem odd that I would disagree with all of them. Let me lay out for you the reasons why and I will let you decide which way to go.
The goal of Entity Framework (EF) was to create a simple way to abstract away the database and allow developers to just work with data objects. Basically, as a developer, EF should simplify your life by allowing you to stay in C# and not think about how the data is getting into the database or back out. That’s the goal. Now, let’s talk about the reality of it. If you look at this simple getting started with EF example, you will see that you need to learn about DBSet, Data Context, Initializers, Seeds, Pluralization, and more. That’s before you take on the more complex example. That doesn’t seem simple to me. It seems like in order to avoid learning SQL, you ended up learning a whole new set of language tools. This isn’t reusing your skills, it is adding a new skill in C# for express purpose of avoiding learning a skill in SQL. Since you still need to know SQL, it doesn’t seem like a good trade-off.
In contrast, my tool of choice is Dapper from the folks who make StackOverflow. I created a whole video on it (found here: https://youtu.be/Et2khGnrIqc). I won’t go into all of the points I covered in that video, but basically Dapper is simple to use and it allows me to use stored procedures, which in turn can help me make my database much more secure.
Now let’s look at the three areas that we should consider when choosing the best data access tool for our needs: speed, simplicity, and ease of maintenance.
When it comes to speed, the speed I think is most important is application speed. How fast is it for our customers. In this category, Dapper wins hands down. You can go to their page on GitHub to see that Dapper is an order of magnitude faster than EF. Now some might argue that speed of development is important as well. I agree, but not at the expense of my customers. When it comes to development speed, EF has a better story once everything is set up. Once you have all of your configuration set, your settings tweaked, and your models built, it is pretty fast to make small changes. Dapper isn’t slow, it is just that you need to make the change in two places (your model and your stored procedure) if you want to add or drop a field.
Simplicity is another area where Dapper crushes EF. In four lines of code, I can get data out of a database and into a List<T>. Try doing that in EF. You will have adapters, context, and more and won’t even have data yet.
Finally, ease of maintenance is another Dapper winner. If I have a database developer on my team, they can work just in SQL. If I use EF, I would need to get a database developer who also knows C#. Either that or I don’t have a database developer on my team but then who optimizes the database? The C# developers?
To summarize, Dapper is quicker, simpler, and easier to maintain. It fits better into an existing organization with existing databases. It is simpler to learn. It is powerful and yet not complex. So, for all of these reasons, I choose Dapper for my data access needs. How about you?