Dapper vs Entity Framework Core: Which Should You Use in .NET?

Dapper and Entity Framework Core are the two most popular ways to talk to SQL Server from .NET. Debates about them often turn into speed contests, but the better question is: how much do you want to write SQL yourself, and how much do you want the framework to do for you?

Dapper vs Entity Framework Core comparison

Dapper in one minute

Dapper is a "micro-ORM": a small library of extension methods on IDbConnection. You write the SQL; Dapper runs it and maps the results to your objects.

using var conn = new SqlConnection(connectionString);

var employees = await conn.QueryAsync<Employee>(
    @"SELECT EmployeeId, FullName, DepartmentId
      FROM dbo.Employee
      WHERE DepartmentId = @DeptId AND IsActive = 1",
    new { DeptId = deptId });

Parameters are passed as an anonymous object, so queries stay safe from SQL injection.

EF Core in one minute

EF Core is a full ORM. You describe your model in C#, write LINQ, and EF Core generates the SQL, tracks changes and saves them, with migrations to evolve the schema.

var employees = await db.Employees
    .Where(e => e.DepartmentId == deptId && e.IsActive)
    .Select(e => new { e.EmployeeId, e.FullName, e.DepartmentId })
    .ToListAsync();

Side-by-side

DapperEF Core
Who writes the SQLYouEF Core (from LINQ)
Raw overheadVery lowLow to moderate; close to Dapper for well-written, no-tracking queries
Change trackingNoYes
Relationships and loadingManual (multi-mapping)Built in (Include, navigation properties)
Schema migrationsSeparate toolBuilt in
Learning curveSmall, if you know SQLLarger: tracking, loading strategies, generated SQL
Complex SQL (CTEs, window functions, hints)Easy: it is just SQLPossible via raw SQL, less natural

Choose Dapper when

  • Your team is strong in SQL and wants full control of every query.
  • The work is read-heavy: reports, dashboards, search screens, APIs returning projections.
  • You work mostly with stored procedures or an existing database you do not own.
  • You need hand-tuned queries with hints, CTEs or window functions.

Choose EF Core when

  • You build a domain-rich application with lots of create, update and delete logic.
  • You want migrations, relationships and change tracking out of the box.
  • Developer productivity and maintainability matter more than squeezing every microsecond.
  • You are happy to learn its performance habits: no-tracking reads, projections and checking generated SQL.

The pragmatic answer: use both

Many production systems use EF Core for everyday CRUD and business logic, and Dapper (or EF Core's raw SQL methods) for a handful of heavy reports and performance-critical queries. They can share the same connection string, and even the same connection:

var conn = db.Database.GetDbConnection();   // EF Core's connection
var rows = await conn.QueryAsync<PayrollSummary>(sql, new { RunId = runId });

If both must take part in one transaction, pass EF Core's current transaction to Dapper as well (for example, db.Database.CurrentTransaction?.GetDbTransaction()).

Performance is mostly about the SQL

Whichever you choose, a missing index or an N+1 pattern will cost far more than the difference between the libraries. Look at the SQL that actually runs, check execution plans for slow queries, and fetch only the columns and rows you need.

Related reading:

Comments

Post a Comment

Popular posts from this blog

How to Read a SQL Server Execution Plan (Beginner's Guide)

Image
When a query is slow, the execution plan tells you exactly what SQL Server did to run it: which indexes it used, how it joined tables and where the time went. Plans can look intimidating, but you only need a few habits to find the problem in most of them. Estimated vs actual plans SQL Server Management Studio (SSMS) can show two kinds of plan: Estimated plan (Ctrl+L): what SQL Server plans to do, without running the query. Useful for queries that are too slow or too risky to run. Actual plan (Ctrl+M, then run the query): the same plan plus what really happened, including actual row counts and warnings. Use this whenever you can. Turn on IO and time statistics at the same time so you have numbers to compare after each change: SET STATISTICS IO, TIME ON; -- run the query with "Include Actual Execution Plan" enabled SET STATISTICS IO, TIME OFF; Read from right to left Data flows from right to left. The operators on the far right read data from tables and indexes; each operato...
Read more

SARGable Queries in SQL Server: Why Functions in WHERE Slow You Down

Image
You add the perfect index, run the query, and SQL Server still scans the whole table. One of the most common reasons is a non-SARGable predicate: a WHERE clause written in a way that stops SQL Server from using the index to seek. The fix is usually a small rewrite. What SARGable means SARGable stands for S earch ARG ument- able . A predicate is SARGable when SQL Server can use it to jump straight to the matching rows in an index (an index seek). If you wrap the indexed column in a function or calculation, SQL Server can no longer search the index for a value; it has to calculate the expression for every row, which means a scan. The rule of thumb: leave the column bare on one side of the comparison , and do any calculation on the other side. Common non-SARGable patterns and their fixes Functions on date columns -- Not SARGable: YEAR() runs on every row WHERE YEAR(OrderDate) = 2026 -- SARGable: a range on the bare column WHERE OrderDate >= '2026-01-01' AND OrderDate < ...
Read more

SQL Server Statistics Explained: Why Your Query Plans Go Wrong

Image
When a query suddenly picks a terrible plan, the root cause is very often statistics . SQL Server's optimizer does not look at your data when it builds a plan; it looks at statistics about your data. If those are missing or out of date, it guesses wrong, and a wrong guess can mean a scan instead of a seek, the wrong join type or a memory spill. What statistics are A statistics object describes how values are distributed in one or more columns. SQL Server creates one automatically for every index, and, with AUTO_CREATE_STATISTICS on, for columns you filter or join on. The optimizer uses them to estimate how many rows each step will return, and those estimates drive almost every plan choice. How to read a statistics object DBCC SHOW_STATISTICS ('dbo.PayrollLine', 'IX_PayrollLine_Run_PayCode'); The output has three parts: Header: when the statistics were last updated, how many rows the table had, and how many rows were sampled . Density vector: how unique the column...
Read more