Dapper or EF Core?
Dapper gives full control of the SQL with very little to learn; EF Core writes the SQL, tracks changes and follows relationships. Choose Dapper when the SQL matters most and EF Core when the objects do, and keep to one per project unless there's a reason.
Journeyman · C# · Entity Framework Core · Updated
After this lesson you can
- Choose between Dapper and EF Core for a project, and explain the choice
Key takeaways
- Dapper gives complete control of the SQL with very little to learn; EF Core writes the SQL, tracks changes and follows relationships.
- Choose Dapper when the SQL matters most: an existing, carefully written database, complex reports, or speed above all.
- Choose EF Core when the objects matter most: an app that's mostly CRUD, data with many relationships, or a fast start.
- Keep to one per project, and add the other only when there's a clear reason.
- Knowing SQL helps with both: with Dapper you write it, and with EF Core you read what it wrote when something is slow.
Both are excellent, both are free, and both are used in real companies every day. The right choice depends on the project and the team.
Side by side
| Dapper | EF Core | |
|---|---|---|
| You write | The SQL | LINQ; EF Core writes the SQL |
| Saving changes | An INSERT, UPDATE or DELETE you write |
Change the objects, call SaveChangesAsync() |
| Relationships | Your joins | Navigation properties and Include |
| Control over the SQL | Complete | Partial: you can read it, and drop down to SQL when needed |
| To learn | Very little, if you know SQL | A lot: tracking, relationships, configuration, migrations |
| Speed | Close to hand-written ADO.NET | A little slower; fine for most apps |
| Creating the database | Your own scripts | Your own scripts, or EF Core's migrations |
| Safe from SQL injection | Yes, with @ parameters |
Yes, by default |
When each shines
Choose Dapper when:
- the database already exists, and its SQL is carefully written, perhaps by a database team, with views and stored procedures;
- queries are complex reports, where you want to write and tune the SQL yourself;
- speed matters a great deal, such as an API answering thousands of requests a second;
- the team knows SQL well, and wants to see exactly what runs.
Choose EF Core when:
- the app is mostly create-read-update-delete on objects, such as an admin site or a typical business app;
- the data has many relationships, and following them in C# saves a lot of joins;
- the team prefers to think in C# objects, and to let the database follow the classes (with migrations);
- you want to get started fast, and fine-tune only the few queries that need it.
One per project
Mixing them is possible (some teams use EF Core for saving and Dapper for heavy reports), but each extra tool is one more thing for everyone to learn. Start with one, and add the other only when there's a clear reason.
Neither is "the right way"
You'll meet both. EF Core is Microsoft's own, so it's the one most tutorials use; many high-traffic systems use Dapper for its speed and control. Knowing SQL makes you better at both: with Dapper you write it, and with EF Core you read what it wrote when something is slow.
The rest of this module keeps to Dapper for the Northwind API, since you already know its SQL inside out. Everything you build would work the same way with EF Core behind the interface.
Check yourself
1 question to try on the lesson page.
So what
Dapper: your SQL, Dapper's mapping. EF Core: your objects, EF Core's SQL. Pick the one that fits the project and the team, and understand SQL either way.
Key terms
- Dapper
- Entity Framework Core