Performance, testing and choosing Dapper vs EF Core — Dapper — The Micro-ORM from Basics to Advanced

8. Performance, testing and choosing Dapper vs EF Core

AdvancedMediumLesson 8 of 8

Performance tips:

Select only needed columns; page on the server (OFFSET/FETCH or keyset paging).
Use correct parameter types (DbString IsAnsi for VARCHAR columns) to avoid implicit conversions that prevent index seeks.
Use QueryMultiple instead of several round trips; TVPs/SqlBulkCopy for bulk.
Dapper caches per SQL text — don't build SQL with embedded values (cache grows without limit and plans aren't reused).
Use QueryUnbufferedAsync for very large results.
Check the execution plan; Dapper is only as fast as your SQL.

Testing: unit-test services by mocking the repository interface; integration-test repositories against a real SQL Server (Testcontainers / LocalDB) — mocking IDbConnection extension methods is impractical.

When to choose what:

Situation	Choice
Complex reporting queries, dashboards, existing stored procedures	Dapper
Rich domain with relationships, change tracking, migrations	EF Core
Read-heavy API endpoints needing maximum speed	Dapper (or EF Core with `AsNoTracking` + projection — often close enough)
Bulk loads / ETL	SqlBulkCopy / TVPs (with or without Dapper)
Mixed	EF Core for commands, Dapper for queries (they can share a connection/transaction via `db.Database.GetDbConnection()`)