Using Dapper over EntityFramework for database operations in .NET Core

We’re entering a new world in which data may be more important than software.
--Tim O’Reilly

In most of the use cases for today’s software, data access plays an important role.
.NET core supports multiple framework options to store and access data in your software application may it be a microservice or a web application.

Entity Framework Core is one of the most recommended options suggested for applications working with relational database. EF Core is an object-relational mapper(ORM) that enables .NET developers to persist objects to and from a data source. It eliminates the need for most of the data access code developers would typically need to write.

Dapper is a simple object mapper for .NET and owns the title of King of Micro ORM in terms of speed and is virtually as fast as using a raw ADO.NET data reader. Dapper operates directly using the IDbConnection interface which is extended by database providers like SQL Server, Oracle, MySQL etc. for their database.

Dapper is known for its high performance and is especially used by developers when they want to write the SQL query themselves with optimal performance or use stored procedures.
But how fast is it compared to EF Core?

To figure this out, as always, I have created a demo project here that compares the same read and write operations between EF Core and Dapper using BenchmarkDotNet. I have used SQL Server as the relational database to insert and retrieve data.

Structure of the database

For this demo, I have created two tables called Athletes and Sports. Before the execution of the benchmarks, I am also clearing down the database and reseeding the data with 16 records in Athletes and 5 records in Sports.

Read Operation

I have created repository methods for EFCore and Dapper each to fetch data from the database. I have used the same criteria for both, which is to fetch the names of all indoor sport athletes older than 25 years of age.

Write Operation

I have created repository methods for EFCore and Dapper each to insert Athlete data into the database. I have used the same data to be inserted in both the methods.

Performance benchmarks for read and write

I have used BenchmarkDotNet to benchmark the performance for the database read and write operations using both EF Core and Dapper.

BenchmarkDotNet helps you to transform methods into benchmarks, track their performance, and share reproducible measurement experiments. The results for these benchmarks are presented in a user-friendly form that highlights all the important facts about your experiment.

I have set the iteration count as 100 iterations. This can be configured by assigning the desired value to the variable numberOfIterations.

Benchmark results

On running the benchmark project, the below summary is what is displayed as output which shows that for Dapper both read and write are faster, almost x2 times, than EF Core for the same kind of operation.

The summary also shows that the memory allocated for Dapper operations is far less than the memory allocated for EF Core operations.

The detailed results for both the read and write operations give detailed statistical information for the benchmark. It also gives a histogram for the the time interval for the database operation. BenchmarkDotNet also allows the measured data to be exported in different formats including plots.

While benchmark results clearly state that Dapper has a higher performance than EF Core for both read and writes, in most instances the performance for database writes is almost comparable. Due to this, some developers prefer to use Dapper for read operations and EF Core for write operations involving complex objects to be written into the database as transforming them into Dapper queries itself may be a cumbersome task.

Dapper is safe from SQL injection with the use of parameters using anonymous objects and also allows you to use custom queries with performance enhancement which gives you better control over the database operations for eg. using with(nolock) in select queries.

Thus we have seen why Dapper is known as King of Micro ORM and how in our example, BenchmarkDotNet helped us showcase that it has a better performance to EF Core. It is important to note that the performance of both EF Core and Dapper vary based on the use case and the type of database operations being performed, but Dapper in general performs better with database read operations.

You can find my demo project that I have created to run this benchmark on my github repo here https://github.com/chaitanya-suvarna/efcore-dapper-benchmark

I hope you found this interesting and useful.

Thank you for reading!

Comments

[Shaiju T]

Nice 😄, Dapper x2 times faster than EF Core doesn't seems good for me because if you are concerned about performance, then you can do it in DB level with raw performance of ADO.NET code.

Also I think writing SQL query like select * from inside C# code is not maintainable. But EF Core looks pretty clean. I have not used Dapper ? What you think ?

[Claudio Valerio]

IMO it really depends on the type of application you're writing, the statistical distribution between read and write operations and other factors, like the production environment, etc.
Both dapper and ef are just tools, to be chosen thinking at the big picture.

For most applications I generally agree with your point of view, ef readability and maintainability worth the cost in performances, especially if you put a sane layer of caching in front of your read ops.

There are other situations (low mem devices, simpler database structure and interaction, still want/need to use a RDBMS as persistence layer...) where Dapper represent a good alternative to raw ado.net.