Dapper vs. Entity Framework

When it comes to Object-Relational Mapping (ORM) in .NET, there are two popular options that are usually considered. Dapper and Entity Framework both let developers work with data in an object-oriented way, but they have differences that can make your life easier when you use them in the right place.

In this article, I’m trying to help my readers to choose the right ORM for their next project. This isn’t meant to make one of these ORMs look bad and the other one good; meanwhile, I have to give my honest opinion about the different benefits and pains that I have experienced using these ORMs.

Query Language

In Dapper, you should use raw SQL queries which is good news if you are comfortable with SQL and those queries are plain text in Visual Studio, so there is no IntelliSense or color coding for your query. For Entity Framework, you write your queries using a query language called LINQ which is very rich and easy to use for complex queries, specifically for developers who have limited SQL experience. When it comes to deciding which ORM is easier to query in, it’s very dependent on the developers’ experience. Based on my personal take, it’s easier to write your queries in SQL itself instead of LINQ because when it comes to complex queries, especially for a database that is not designed very well, it becomes very hard to read and maintain LINQ but SQL feels more natural. Not having any help in Visual Studio is very annoying and definitely a con for Dapper, but you can write your Queries in a more friendly environment (like SSMS for MSSQL) and copy the final version to your C# code.

In the following example, you can see that LINQ can quickly become harder to read for more complicated queries.

SELECT p.*, COUNT(DISTINCT oi.orderId) AS orderCount, SUM(oi.quantity * oi.price) AS revenue
FROM Products p
LEFT JOIN OrderItems oi ON p.id = oi.productId

Now, the LINQ version :

var products = dbContext.Products
    .Select(p => new {
        Product = p,
        OrderCount = p.OrderItems
            .Select(oi => oi.Order.CustomerId)
        Revenue = p.OrderItems
            .Sum(oi => oi.Quantity * oi.Price)


It’s not very accurate to talk about performance without having a benchmark to back up your claims, and the EF versions can have different results in the benchmark based on the version used. Maybe that would be a great topic for another article, but today I want to talk about the performance from my personal experiences. In my opinion, if you compare them in simple queries they both are going to have close outcomes, but when the queries become huge and complicated and Dapper is the winner.

Entity Framework is a full-feature ORM and comes with a lot that can slow down your work with the database if you are not really going to use those features, it doesn’t worth trading the features with performance.

Entity Framework Features That Dapper Doesn’t Have

Lazy loading: Won’t retrieve entities from the database until they are accessed in the code.

Code-first development: You can define your SQL schema in C# code using annotations and ask EF to implement them in the database.

Query caching: Stores frequently executed database queries in memory to improve performance by reducing round-trips to the database.

Change tracking: Keeps track of changes made to objects in memory and automatically generates SQL statements to update the database accordingly.

Debugging a Problem

Sometimes it’s not easy debugging Entity Framework since you don’t know what’s your final query, especially when you have a performance issue, but you can always log the generated query and find the issue there but you have limited control over exactly what should be the generated query. On the other hand, you can exactly see what runs against the database when you are using Dapper, and you can test the performance before using it in your project.

Choosing the Right ORM for Your .NET Project

When you want to choose between these two ORMs there are questions that you need to ask yourself to be able to make the right decision. The following are the questions I ask myself before starting a project.

  1. What is the complexity of your data model and queries?
  2. What are the performance requirements of your application?
  3. What is your experience with writing SQL queries?
  4. Does your project require code-first development or can you work with an existing database schema?
  5. What features and capabilities do your application need, are you going to use the feature Entity Framework has?


After all of the technical comparisons, I think it’s important to understand what skills your team members have and which ORM will fit them. Anyway, you aren’t going to get a good result If you chose Entity Framework and your team is not capable of using the features properly, or if you use Dapper and your team doesn’t know how to write good SQL queries. In both cases, you are going to regret your decision so make sure to know your team before everything.