Data access in .NET: EF Core, Dapper and the rest

One page for the decision behind the requirement “EF Core, Dapper, or another ORM/data-access framework”: what each option actually does, where its cost sits, and how to combine them without turning the data layer into two competing truths.

1. The four families of data access

“ORM or Dapper” is really a choice between four levels of abstraction. Each one trades control for convenience, and the trade is not symmetrical: what you give up is not the same thing at every level.

The decision is not “which is faster”. Dapper wins raw microbenchmarks almost always, because it does almost nothing: no expression tree to parse, no change tracker, no identity map. EF Core wins on the work it removes — migrations, relationship management, and the ability to express a query once in typed code. Both statements are true at the same time, which is why mature systems mix them.

2. EF Core — a full O/RM

EF Core maps a .NET object model to a relational schema and translates LINQ expression trees into SQL. Its value is not the SELECT it writes; it is the lifecycle around that SELECT.

2.1 The model and the mapping

• Entities have identity and are tracked; owned types and (since EF 8) complex types do not.
• Conventions first: Id/<Type>Id is the key, navigation properties become relationships, and IEntityTypeConfiguration<T> classes hold the rest.
• Migrations are generated C# that alter the schema; they are code, reviewed like code, and applied in a controlled order.

public sealed class OrderConfiguration : IEntityTypeConfiguration<Order>
{
    public void Configure(EntityTypeBuilder<Order> b)
    {
        b.ToTable("Orders");
        b.HasKey(o => o.Id);
        b.Property(o => o.Number).HasMaxLength(32).IsRequired();
        b.HasIndex(o => new { o.CustomerId, o.CreatedAt });

        // Complex type: value semantics, no identity, one JSON column
        b.ComplexProperty(o => o.Shipping, c => c.ToJson());
    }
}

2.2 The change tracker

Reads that go through the tracker pay for identity resolution and snapshotting. That is what makes SaveChanges able to compute a diff — and what makes a 50 000-row read in a request expensive for no reason.

// read-only API path: no tracking, no identity map
var list = await db.Orders
    .AsNoTracking()
    .Where(o => o.CustomerId == id)
    .OrderByDescending(o => o.CreatedAt)
    .Select(o => new OrderDto(o.Id, o.Number, o.Total))
    .Take(50)
    .ToListAsync(ct);

// write path: tracked, one unit of work
var order = await db.Orders.Include(o => o.Lines).SingleAsync(o => o.Id == id, ct);
order.AddLine(sku, qty);
await db.SaveChangesAsync(ct);

2.3 What EF Core does well

2.4 Where it costs you

• Translation surprises: a LINQ expression that cannot translate either throws or silently evaluates on the client. Always inspect the SQL for hot queries.
• Cartesian explosion: several Includes over collections multiply rows; AsSplitQuery() fixes it at the cost of more round-trips.
• N+1 by lazy loading: convenient, invisible, and expensive in loops.
• Startup: model building is not free; the first query in a process pays for it (consider compiled models).

3. What EF Core 10 changed

EF Core 10 shipped in November 2025 as an LTS release supported until November 2028, and requires the .NET 10 runtime. The items below change day-to-day design decisions, not just micro-performance.

4. Dapper — a micro-ORM

Dapper adds three things on top of DbConnection: parameter binding from an object, mapping of the result set into objects, and a set of helpers for multi-mapping and multi-result queries. Everything else — SQL, schema coupling, transaction scope — stays yours.

4.1 The core API

const string sql = @"
SELECT o.Id, o.Number, o.Total, c.Name AS CustomerName
FROM Orders o
JOIN Customers c ON c.Id = o.CustomerId
WHERE o.CustomerId = @customerId AND o.CreatedAt >= @from
ORDER BY o.CreatedAt DESC
OFFSET @skip ROWS FETCH NEXT @take ROWS ONLY;";

var rows = await connection.QueryAsync<OrderRow>(sql, new
{
    customerId,
    from,
    skip = (page - 1) * size,
    take = size
});

4.2 Multi-mapping and multiple result sets

var sql = @"
SELECT o.Id, o.Number, l.Sku, l.Quantity
FROM Orders o
LEFT JOIN OrderLines l ON l.OrderId = o.Id
WHERE o.Id = @id;";

var order = (await connection.QueryAsync<Order, Line, Order>(
    sql,
    (o, l) => { o.Lines.Add(l); return o; },
    new { id },
    splitOn: "Sku")).First();

// two result sets, one round-trip
using var multi = await connection.QueryMultipleAsync(
    "SELECT * FROM Orders WHERE Id = @id; SELECT * FROM OrderLines WHERE OrderId = @id;",
    new { id });
var head = await multi.ReadSingleAsync<Order>();
var lines = (await multi.ReadAsync<Line>()).ToList();

4.3 What you must remember

• Buffering: Query buffers the whole result by default. For large reads use QueryUnbufferedAsync and stream.
• No tracking: if you load the same row twice you get two objects. That is a feature, and a source of bugs when people assume identity.
• Schema coupling: rename a column in SQL and the C# property silently stops being filled — unless you test with a real database.
• No migrations: schema changes are your responsibility (DbUp, Flyway, EF migrations used only for DDL, or hand-written scripts).
• SQL injection: always parameters; never string concatenation. Dapper passes parameters, it does not sanitize your SQL.

4.4 When Dapper is the right answer

• Reporting and read models with hand-tuned SQL, window functions, CTEs, or MERGE.
• Bulk operations and set-based updates where you want one statement, not N tracked entities.
• Legacy schemas that do not follow ORM conventions and cannot be remodelled.
• Hot paths measured to be dominated by EF Core translation or tracking.

5. Other frameworks

6. Side-by-side comparison

7. Patterns

7.1 Repository and unit of work

DbContext is already a unit of work and a repository over its DbSets. Wrapping it in IRepository<T> usually produces a leaky abstraction: IQueryable escapes anyway, or you lose Include, projections and filters. Prefer a use-case-oriented interface over a generic one.

// Prefer this
public interface IOrderStore
{
    Task<Order?> FindAsync(OrderId id, CancellationToken ct);
    Task AddAsync(Order order, CancellationToken ct);
    Task<IReadOnlyList<OrderSummary>> ListRecentAsync(Guid customerId, int take, CancellationToken ct);
}

// Over this: it re-exposes the ORM with extra steps
public interface IRepository<T> where T : class
{
    IQueryable<T> Query();
    Task<T?> GetByIdAsync(object id);
    // ...
}

7.2 The read/write split

Keep the write model expressive (EF Core, aggregates, invariants) and let reads go straight to SQL (Dapper) with DTOs shaped for the screen or the API contract. The boundary is a namespace, not a distributed system:

Orders/            // EF Core: aggregates, invariants, SaveChanges
Orders/Queries/    // Dapper: SELECTs returning DTOs
Infrastructure/    // DbContext, connection factory, migrations

7.3 Specifications

Useful when the same filtering rule is reused across use cases; harmful when it becomes a second query language. If a specification needs three Includes and a projection, it is a query, not a specification.

8. Performance: where each one hurts

8.1 Round-trip arithmetic

Data-access cost is dominated by round-trips, not by mapping. If a request performs n queries at latency L, the floor is:

A 2 ms local query becomes 40 ms across an availability zone. This is why N+1 hurts more in production than on a laptop, and why batching beats micro-optimizing the mapper.

8.2 Frequent EF Core fixes

• AsNoTracking() + Select into a DTO for read endpoints.
• AsSplitQuery() when two or more collection Includes multiply rows.
• Keyset pagination instead of growing OFFSET; OFFSET 100000 reads and discards 100 000 rows.
• EF.CompileAsyncQuery for a hot query built in a loop.
• Projection pushdown: filter and page before materializing, not after ToList().
• Check the generated SQL and the actual plan — ToQueryString() and EXPLAIN.

8.3 Frequent Dapper fixes

• QueryUnbufferedAsync for large result sets; buffering 500 000 rows is a memory incident.
• Reuse a DbConnection from a pool; do not open per call without using discipline.
• Parameterize IN lists properly; Dapper expands @ids into many parameters, which is good, but very large lists need a table-valued parameter or a temp table.
• Select only the columns the DTO needs; SELECT * plus a join is how read models become slow.

9. Transactions, concurrency and migrations

9.1 One transaction, two tools

EF Core and Dapper can share a transaction: open it on the DbContext connection and pass the same connection and transaction to Dapper.

await using var tx = await db.Database.BeginTransactionAsync(ct);

var order = await db.Orders.SingleAsync(o => o.Id == id, ct);
order.MarkPaid();
await db.SaveChangesAsync(ct);              // EF Core

await db.Database.GetDbConnection().ExecuteAsync(
    "INSERT INTO AuditLog (EntityId, Action, At) VALUES (@id, 'paid', SYSUTCDATETIME())",
    new { id }, tx);                         // Dapper, same transaction

await tx.CommitAsync(ct);

9.2 Concurrency

• Optimistic: rowversion/xmin plus a retry loop on DbUpdateConcurrencyException. Default for APIs.
• Pessimistic: SELECT ... FOR UPDATE or UPDLOCK, only inside short transactions; long locks turn into timeouts under load.
• Idempotency: a unique key on the command id makes retries safe regardless of the data-access tool.

9.3 Migrations in delivery

• Generate scripts in CI (dotnet ef migrations script --idempotent) and review them; do not run Database.Migrate() from application startup in production.
• Expand → migrate → contract: add nullable column, backfill in batches, switch reads, drop the old column in a later release.
• Never mix a breaking DDL change with a code deploy that depends on it in the same step.

10. Testing the data layer

11. Decision guide

1. Is the domain non-trivial and mutated through invariants? EF Core for the write model. If not, a micro-ORM or raw SQL is enough.
2. Does the read need SQL that LINQ expresses badly (window functions, CTEs, pivots, MERGE)? Dapper for that query, in the same project.
3. Is the schema owned by the team? If yes, EF migrations. If not, external migration tooling that matches the DBA process.
4. Is the hot path measured? Optimize the round-trips and the plan first; swap the mapper only if it is provably the bottleneck.
5. Can two mappers drift? Keep one schema, one migration source, and tests that exercise both paths against a real database.

Review checklist

• Read endpoints use AsNoTracking and projections, not full entities.
• No lazy loading in request paths; Includes were checked for cartesian growth.
• Every list endpoint is paginated, and pagination is keyset where the table is large.
• All SQL is parameterized; raw SQL concatenation is justified and reviewed.
• Transactions are short, and external calls are outside them.
• Migrations are generated as scripts and reviewed; no automatic migrate on startup in production.
• Integration tests run against the same engine as production.
• Sensitive values do not appear in logs (EF Core 10 redacts inlined constants by default, but check the rest).

12. Sources

• What's New in EF Core 10 — LTS release notes: named query filters, complex types, parameterized collections, LeftJoin, JSON and vector support.
• Single vs. split queries — cartesian explosion and when to split.
• Global query filters — soft delete and multi-tenancy.
• Dapper — repository and API surface.
• linq2db — LINQ over SQL with explicit control.
• Marten — document database and event store on PostgreSQL.
• Provider ecosystem — an example of an EF Core provider outside Microsoft.