The question “Should we use EF Core or Dapper?” often arrives after an application becomes slow or a developer dislikes the current data-access code. Those are useful signals to investigate, but they do not identify the cause by themselves. A poor query can remain poor after changing libraries, while a familiar approach can become expensive if the team uses it without understanding its behaviour.
For a business application, the decision should connect data-access responsibilities to the team's ability to maintain them. Consider query shape, transaction rules, change tracking, schema evolution and diagnostics. The right comparison starts with representative operations rather than a general claim that one tool is always faster or cleaner.
Compare actual operations rather than entire applications
Select a few operations with different characteristics. A customer-editing workflow, an order with several related records and a read-only management report will expose different needs. Record what each operation must load, validate and persist, including its performance and consistency requirements.
For a hypothetical wholesaler, the report may need a carefully shaped aggregate query, while order editing benefits from clear handling of related state changes. Evaluate those operations independently before making an application-wide rule. A decision that suits a report need not dictate how every transaction is implemented.
Measure the current behaviour if the system already exists. Capture query count, returned data size and elapsed time under representative conditions. This creates a baseline against which a proposed change can be assessed and helps avoid replacing a library to solve an indexing or over-fetching problem.
Understand which responsibilities each approach carries
EF Core provides an object-relational mapping approach with capabilities such as LINQ queries and change tracking. Its efficient-querying guidance discusses projection, result limits and related-data loading. Dapper's official repository describes an object mapper that extends database connections and maps query results. Review the actual features needed by the application. EF Core querying guidance and Dapper's official repository.
With explicit SQL, the team owns the query text and must keep its mapping and database assumptions correct. With a richer mapping layer, the team still needs to inspect generated queries and understand when data is loaded or tracked. Neither approach removes the need to understand the database workload.
Write down the responsibilities that remain outside the selected library: authorisation, tenant boundaries, business validation and useful failure reporting. Those concerns should not be assumed to work automatically because an operation uses a familiar data-access abstraction.
Test performance with equivalent work
A fair comparison returns the same information and applies the same conditions. If one implementation fetches a complete object graph and another selects three columns, the test is comparing different work as well as different tools. First determine whether the smaller result is what the application actually needs.
Use realistic data volumes and examine database execution behaviour. Include the number of round trips and the cost of repeated queries inside loops. A fast isolated query can still produce a slow page when it is executed hundreds of times for individual records.
Keep correctness in the acceptance criteria. A report that is faster because it omits cancelled orders incorrectly has not improved the application. Compare outputs against agreed examples and preserve the relevant business definitions. Our SQL Server performance guide provides a complementary investigation sequence.
Treat writes and transactions as business operations
For a write workflow, identify which changes must succeed together. Specify how the application handles validation failure, a database constraint and a concurrent update. The chosen library affects implementation, but the business requirements for the transaction should remain explicit and independently reviewable.
Avoid spreading a single operation across data-access paths without a clear transaction strategy. If a team combines EF Core and Dapper, it must deliberately manage the relevant connection and transaction boundaries. Merely using both against the same database does not make their changes one atomic operation.
Consider how generated identifiers, affected-row counts and concurrency checks are handled. These details can determine whether the application knows that a write succeeded or that the underlying record changed. Include failure and conflict cases in the prototype rather than evaluating only a successful insert and read.
Evaluate the maintenance experience
Ask another developer to modify a representative query and diagnose a failure. Observe whether they can find the SQL, understand its parameters and connect it to the calling workflow. A concise implementation is useful only if the team can reason about what it does and change it safely.
Review the strategy for schema changes. Explicit queries, mappings and generated queries can all be affected by a renamed column or changed relationship. Decide which checks will reveal a mismatch and how the release process will verify compatibility with the deployed schema.
Parameterise values and keep user-controlled input out of dynamically constructed SQL syntax. Where identifiers or sorting expressions must vary, use a constrained mapping to approved choices. This responsibility belongs in the implementation and review process regardless of which data-access library is selected.
Use mixed approaches only with a clear boundary
A team may decide to retain EF Core for ordinary application persistence and use an explicit query for a demanding report. That can be reasonable when the boundary is documented, the benefit is measured and both paths follow the same access and observability rules.
Avoid letting exceptions multiply without review. If every new feature chooses its own connection handling, naming conventions and error behaviour, the maintenance cost can exceed the benefit of individual optimisations. Keep a small set of supported patterns and explain when each is appropriate.
Worktechlabs can help review .NET data access through representative queries, transaction behaviour and maintainability. The useful outcome is an evidence-based choice for the workload, with fewer surprises for the next developer and a measurable improvement where performance was the original concern.
Official sources and further reading
- Microsoft: efficient querying in EF Core — reducing unnecessary database work.
- Dapper maintainers: official repository and documentation — supported usage and mapping examples.
- Microsoft: EF Core concurrency conflicts — behaviour to account for in competing updates.
