Dapper vs Entity Framework Core in .NET – Complete End-to-End Guide

Introduction

When developing modern ASP.NET Core Web API applications, one of the most important decisions is how the application communicates with the database.

Two popular approaches in the .NET ecosystem are:

• Entity Framework Core (EF Core)

• Dapper

Both are powerful, but they solve the database-access problem differently.

EF Core is a full-featured Object-Relational Mapper (ORM), while Dapper is a lightweight micro-ORM that provides a thin layer over ADO.NET.

A common interview question is:

"What is the difference between Dapper and Entity Framework Core, and when would you use each?"

This article explains the differences from beginner to production level.

---

1. What is Entity Framework Core?

Entity Framework Core (EF Core) is Microsoft's modern, cross-platform ORM for .NET.

ORM stands for:

Object Relational Mapping

It allows developers to work with database tables using C# classes and LINQ instead of writing SQL for every operation.

For example, suppose we have a database table:

CREATE TABLE Employees
(
    Id INT PRIMARY KEY IDENTITY,
    Name NVARCHAR(100),
    Department NVARCHAR(100),
    Salary DECIMAL(18,2)
);

In EF Core, we can create:

public class Employee
{
    public int Id { get; set; }

    public string Name { get; set; }

    public string Department { get; set; }

    public decimal Salary { get; set; }
}

Then query the database using LINQ:

var employees = await dbContext.Employees
    .Where(x => x.Department == "IT")
    .ToListAsync();

EF Core generates the appropriate SQL behind the scenes.

---

2. What is Dapper?

Dapper is a lightweight micro-ORM for .NET.

It was originally created by the Stack Overflow team and is widely used for high-performance database access.

Unlike EF Core, Dapper does not attempt to provide a complete ORM framework.

You normally write the SQL yourself:

var sql = """
          SELECT Id, Name, Department, Salary
          FROM Employees
          WHERE Department = @Department
          """;

var employees = await connection.QueryAsync<Employee>(
    sql,
    new { Department = "IT" });

Dapper executes the SQL and maps the returned rows to the Employee C# class.

---

3. Dapper vs EF Core – High-Level Difference

Feature	Dapper	EF Core
Type	Micro ORM	Full ORM
SQL	Developer writes SQL	EF can generate SQL
LINQ	Limited/direct SQL approach	Extensive LINQ support
Change Tracking	No built-in change tracker	Yes
Migrations	No	Yes
Relationships	Manual SQL/mapping	Built-in relationship mapping
Lazy Loading	No built-in ORM-style lazy loading	Supported with configuration
Performance	Generally very fast	Generally good, but more abstraction
Control over SQL	Very high	Medium/High
Learning Curve	Relatively low	Higher
CRUD	SQL-based	Object-based/LINQ
Transactions	ADO.NET transactions	DbContext transactions
Complex queries	Excellent when SQL is known	Excellent with LINQ, but SQL knowledge still useful
Stored Procedures	Excellent	Supported
Change Tracking	No	Yes
Database-first	Manual	Supported
Code-first	No EF-style migrations	Supported
Best suited for	SQL-centric/high-performance applications	Domain/application-centric applications

---

4. Architecture Difference

The biggest conceptual difference is the abstraction level.

Dapper

Application
     |
     v
Repository
     |
     v
Dapper
     |
     v
ADO.NET
     |
     v
SQL Server

You control the SQL.

---

EF Core

Application
     |
     v
Repository / Service
     |
     v
DbContext
     |
     v
EF Core
     |
     v
LINQ
     |
     v
SQL Generation
     |
     v
SQL Server

EF Core provides more abstraction.

---

5. Basic EF Core Setup

Suppose we are developing:

ASP.NET Core Web API
        |
        v
EmployeeService
        |
        v
EmployeeRepository
        |
        v
EF Core
        |
        v
Azure SQL / SQL Server

Install the SQL Server provider:

dotnet add package Microsoft.EntityFrameworkCore.SqlServer

For migrations:

dotnet add package Microsoft.EntityFrameworkCore.Tools

---

6. Create DbContext

public class EmployeeDbContext : DbContext
{
    public EmployeeDbContext(
        DbContextOptions<EmployeeDbContext> options)
        : base(options)
    {
    }

    public DbSet<Employee> Employees { get; set; }
}

---

7. Configure Connection String

{
  "ConnectionStrings": {
    "DefaultConnection":
      "Server=localhost;Database=EmployeeDb;Trusted_Connection=True;TrustServerCertificate=True"
  }
}

Register DbContext:

builder.Services.AddDbContext<EmployeeDbContext>(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("DefaultConnection")));

---

8. EF Core CRUD Operations

Create

var employee = new Employee
{
    Name = "John",
    Department = "IT",
    Salary = 75000
};

dbContext.Employees.Add(employee);

await dbContext.SaveChangesAsync();

EF Core generates an INSERT statement.

---

9. Read

var employee = await dbContext.Employees
    .FirstOrDefaultAsync(x => x.Id == 10);

---

10. Read Multiple Records

var employees = await dbContext.Employees
    .Where(x => x.Department == "IT")
    .ToListAsync();

---

11. Update

var employee = await dbContext.Employees
    .FirstOrDefaultAsync(x => x.Id == 10);

if (employee != null)
{
    employee.Salary = 85000;

    await dbContext.SaveChangesAsync();
}

EF Core detects the modified property using change tracking.

---

12. Delete

var employee = await dbContext.Employees
    .FindAsync(10);

if (employee != null)
{
    dbContext.Employees.Remove(employee);

    await dbContext.SaveChangesAsync();
}

---

13. Dapper Setup

Install Dapper:

dotnet add package Dapper

For SQL Server:

dotnet add package Microsoft.Data.SqlClient

---

14. Dapper Connection

using Microsoft.Data.SqlClient;
using System.Data;

public class EmployeeRepository
{
    private readonly string _connectionString;

    public EmployeeRepository(IConfiguration configuration)
    {
        _connectionString =
            configuration.GetConnectionString("DefaultConnection")!;
    }

    private IDbConnection CreateConnection()
    {
        return new SqlConnection(_connectionString);
    }
}

---

15. Dapper SELECT

public async Task<IEnumerable<Employee>> GetEmployeesAsync()
{
    using var connection = CreateConnection();

    const string sql = """
        SELECT Id, Name, Department, Salary
        FROM Employees
        """;

    return await connection.QueryAsync<Employee>(sql);
}

---

16. Dapper SELECT By ID

public async Task<Employee?> GetEmployeeAsync(int id)
{
    using var connection = CreateConnection();

    const string sql = """
        SELECT Id, Name, Department, Salary
        FROM Employees
        WHERE Id = @Id
        """;

    return await connection.QuerySingleOrDefaultAsync<Employee>(
        sql,
        new { Id = id });
}

Notice:

WHERE Id = @Id

and:

new { Id = id }

Dapper maps the parameter safely.

---

17. Dapper INSERT

public async Task<int> CreateEmployeeAsync(Employee employee)
{
    using var connection = CreateConnection();

    const string sql = """
        INSERT INTO Employees
        (
            Name,
            Department,
            Salary
        )
        VALUES
        (
            @Name,
            @Department,
            @Salary
        );

        SELECT CAST(SCOPE_IDENTITY() AS INT);
        """;

    return await connection.ExecuteScalarAsync<int>(
        sql,
        employee);
}

---

18. Dapper UPDATE

public async Task<int> UpdateEmployeeAsync(Employee employee)
{
    using var connection = CreateConnection();

    const string sql = """
        UPDATE Employees
        SET
            Name = @Name,
            Department = @Department,
            Salary = @Salary
        WHERE Id = @Id
        """;

    return await connection.ExecuteAsync(sql, employee);
}

---

19. Dapper DELETE

public async Task<int> DeleteEmployeeAsync(int id)
{
    using var connection = CreateConnection();

    const string sql = """
        DELETE FROM Employees
        WHERE Id = @Id
        """;

    return await connection.ExecuteAsync(
        sql,
        new { Id = id });
}

---

20. Query vs Execute in Dapper

This is an important interview topic.

Query

Use Query when you expect rows back.

var employees =
    await connection.QueryAsync<Employee>(sql);

Execute

Use Execute for INSERT, UPDATE, DELETE.

var affectedRows =
    await connection.ExecuteAsync(sql);

ExecuteScalar

Use when you want one value.

var employeeId =
    await connection.ExecuteScalarAsync<int>(sql);

---

21. Entity Framework Core Change Tracking

One of EF Core's major features is change tracking.

For example:

var employee =
    await dbContext.Employees
        .FirstAsync(x => x.Id == 10);

employee.Salary = 100000;

await dbContext.SaveChangesAsync();

EF Core knows that Salary changed.

It generates the UPDATE statement.

---

22. Dapper Does Not Track Changes

Dapper does not maintain an entity state.

For example:

var employee = await connection.QuerySingleAsync<Employee>(
    sql,
    new { Id = 10 });

employee.Salary = 100000;

Nothing happens automatically.

You must execute an UPDATE yourself:

await connection.ExecuteAsync(
    updateSql,
    employee);

---

23. AsNoTracking in EF Core

When you only need to read data, change tracking may not be required.

Use:

var employees = await dbContext.Employees
    .AsNoTracking()
    .ToListAsync();

This can reduce tracking overhead for read-only queries.

This is especially useful in:

Reporting
Dashboards
Search APIs
Read-only endpoints
Large result sets

---

24. Relationships in EF Core

Suppose we have:

Department
    |
    +---- Employee
    +---- Employee
    +---- Employee

Entities:

public class Department
{
    public int Id { get; set; }

    public string Name { get; set; }

    public ICollection<Employee> Employees { get; set; }
        = new List<Employee>();
}

Employee:

public class Employee
{
    public int Id { get; set; }

    public string Name { get; set; }

    public int DepartmentId { get; set; }

    public Department Department { get; set; }
}

EF Core can configure the relationship.

modelBuilder.Entity<Employee>()
    .HasOne(e => e.Department)
    .WithMany(d => d.Employees)
    .HasForeignKey(e => e.DepartmentId);

---

25. Dapper Relationships

Dapper doesn't automatically manage relationships like EF Core.

You normally write SQL joins.

SELECT
    e.Id,
    e.Name,
    d.Id,
    d.Name
FROM Employees e
INNER JOIN Departments d
    ON e.DepartmentId = d.Id

Then map the result manually using Dapper's multi-mapping capabilities or project into DTOs.

---

26. EF Core Include

EF Core provides Include.

var employees = await dbContext.Employees
    .Include(x => x.Department)
    .ToListAsync();

This tells EF Core to load the related department data.

---

27. Dapper Stored Procedures

Dapper works very well with stored procedures.

Example:

CREATE PROCEDURE GetEmployeesByDepartment
    @Department NVARCHAR(100)
AS
BEGIN
    SELECT
        Id,
        Name,
        Department,
        Salary
    FROM Employees
    WHERE Department = @Department;
END

Dapper:

var employees =
    await connection.QueryAsync<Employee>(
        "GetEmployeesByDepartment",
        new
        {
            Department = "IT"
        },
        commandType: CommandType.StoredProcedure);

---

28. EF Core Stored Procedures

EF Core can also execute stored procedures.

For example, raw SQL can be used:

var employees =
    await dbContext.Employees
        .FromSqlInterpolated(
            $"EXEC GetEmployeesByDepartment {"IT"}")
        .ToListAsync();

EF Core also provides APIs for executing SQL commands where appropriate.

The important point is:

Choosing EF Core does not mean you can never use SQL or stored procedures.

---

29. SQL Injection

Both Dapper and EF Core can be used safely.

The important thing is parameterization.

Dapper

const string sql = """
    SELECT *
    FROM Employees
    WHERE Department = @Department
    """;

var employees = await connection.QueryAsync<Employee>(
    sql,
    new { Department = department });

Avoid building SQL using string concatenation:

var sql =
    "SELECT * FROM Employees WHERE Department = '" +
    department +
    "'";

---

30. EF Core Parameterization

LINQ queries are parameterized by EF Core.

var employees = await dbContext.Employees
    .Where(x => x.Department == department)
    .ToListAsync();

EF Core generates parameterized SQL.

---

31. Transactions with Dapper

Dapper uses ADO.NET transactions.

using var connection = CreateConnection();

connection.Open();

using var transaction = connection.BeginTransaction();

try
{
    await connection.ExecuteAsync(
        insertEmployeeSql,
        employee,
        transaction);

    await connection.ExecuteAsync(
        updateDepartmentSql,
        department,
        transaction);

    transaction.Commit();
}
catch
{
    transaction.Rollback();
    throw;
}

---

32. Transactions with EF Core

EF Core provides transaction support through Database.

await using var transaction =
    await dbContext.Database.BeginTransactionAsync();

try
{
    dbContext.Employees.Add(employee);

    await dbContext.SaveChangesAsync();

    department.Budget += 1000;

    await dbContext.SaveChangesAsync();

    await transaction.CommitAsync();
}
catch
{
    await transaction.RollbackAsync();
    throw;
}

---

33. EF Core Migrations

One of the major advantages of EF Core is migrations.

For example:

dotnet ef migrations add InitialCreate

Then:

dotnet ef database update

If you add a property:

public string Email { get; set; }

you can create another migration:

dotnet ef migrations add AddEmployeeEmail

Then:

dotnet ef database update

EF Core manages schema changes through migrations.

---

34. Does Dapper Support Migrations?

No.

Dapper itself is not a database schema migration framework.

You can use tools such as:

• SQL scripts

• DbUp

• FluentMigrator

• Flyway

• Liquibase

• CI/CD database migration processes

For example:

Application
    |
    +---- Dapper
    |
    +---- SQL Scripts
    |
    +---- Migration Tool
    |
    v
SQL Server

---

35. Performance Comparison

A common misconception is:

"Dapper is always faster than EF Core."

That is too simplistic.

Dapper has a smaller abstraction layer and often performs very well for straightforward SQL queries.

EF Core has additional capabilities such as:

• Change tracking

• Identity resolution

• LINQ translation

• Relationship handling

• Model metadata

• State management

These features have overhead.

However, properly written EF Core queries can perform very well.

For example:

var employees = await dbContext.Employees
    .AsNoTracking()
    .Where(x => x.Department == "IT")
    .Select(x => new EmployeeDto
    {
        Id = x.Id,
        Name = x.Name
    })
    .ToListAsync();

This avoids retrieving unnecessary columns and avoids tracking.

---

36. Performance Depends on SQL and Database Design

Database performance is not determined only by Dapper or EF Core.

Other factors include:

Indexes
Query design
Execution plan
Database schema
Network latency
Connection pooling
Number of records
Pagination
Locking
Blocking
CPU
Memory
I/O
Database configuration

For example, a poorly written Dapper query can be slower than a well-written EF Core query.

---

37. Pagination with Dapper

const string sql = """
    SELECT Id, Name, Department, Salary
    FROM Employees
    ORDER BY Id
    OFFSET @Offset ROWS
    FETCH NEXT @PageSize ROWS ONLY
    """;

var employees = await connection.QueryAsync<Employee>(
    sql,
    new
    {
        Offset = (pageNumber - 1) * pageSize,
        PageSize = pageSize
    });

---

38. Pagination with EF Core

var employees = await dbContext.Employees
    .AsNoTracking()
    .OrderBy(x => x.Id)
    .Skip((pageNumber - 1) * pageSize)
    .Take(pageSize)
    .ToListAsync();

---

39. Repository Pattern with EF Core

public interface IEmployeeRepository
{
    Task<Employee?> GetByIdAsync(int id);

    Task<IEnumerable<Employee>> GetAllAsync();

    Task AddAsync(Employee employee);

    Task UpdateAsync(Employee employee);

    Task DeleteAsync(int id);
}

Implementation:

public class EmployeeRepository : IEmployeeRepository
{
    private readonly EmployeeDbContext _context;

    public EmployeeRepository(EmployeeDbContext context)
    {
        _context = context;
    }

    public async Task<Employee?> GetByIdAsync(int id)
    {
        return await _context.Employees
            .FirstOrDefaultAsync(x => x.Id == id);
    }
}

---

40. Repository Pattern with Dapper

public class EmployeeRepository : IEmployeeRepository
{
    private readonly string _connectionString;

    public EmployeeRepository(IConfiguration configuration)
    {
        _connectionString =
            configuration.GetConnectionString("DefaultConnection")!;
    }

    public async Task<Employee?> GetByIdAsync(int id)
    {
        using var connection =
            new SqlConnection(_connectionString);

        const string sql = """
            SELECT Id, Name, Department, Salary
            FROM Employees
            WHERE Id = @Id
            """;

        return await connection.QuerySingleOrDefaultAsync<Employee>(
            sql,
            new { Id = id });
    }
}

---

41. CQRS with Dapper and EF Core

A very common enterprise architecture is:

                 API
                  |
             Application
                  |
             +----+----+
             |         |
         Commands    Queries
             |         |
             v         v
          EF Core    Dapper
             |         |
             v         v
          Database   Database

For example:

Command

Create employee:

POST /employees
       |
       v
Command Handler
       |
       v
EF Core
       |
       v
SQL Server

Query

Get employees:

GET /employees
       |
       v
Query Handler
       |
       v
Dapper
       |
       v
SQL Server

This approach can combine the strengths of both technologies.

---

42. Real-Time Enterprise Example

Consider a BPO workforce-management application.

The system contains:

Forecast Service
Workforce Service
Capacity Service
Hiring Service
Employee Service
Reporting Service

Suppose the Reporting Service needs a complicated dashboard query:

Employee
    |
Department
    |
Skill
    |
Shift
    |
Forecast
    |
Actual Volume
    |
Utilization

The query may involve:

• Multiple JOINs

• Aggregations

• Window functions

• CTEs

• Stored procedures

• Complex filtering

Dapper can be a strong choice when the team wants precise control over the SQL.

For standard application CRUD, EF Core may provide faster development.

Therefore:

CRUD / Domain Logic
       |
     EF Core

Complex Reporting
       |
     Dapper

This is a hybrid approach.

---

43. Can We Use Dapper and EF Core in the Same Application?

Yes.

There is no requirement to choose only one.

For example:

ASP.NET Core API
       |
       +----------------+
       |                |
   EF Core           Dapper
       |                |
       +-------+--------+
               |
          SQL Server

Use EF Core for:

Create
Update
Delete
Domain operations
Change tracking
Relationships

Use Dapper for:

Reports
Complex queries
Read-heavy APIs
Stored procedures
Performance-sensitive queries

---

44. Hybrid Repository Example

public class EmployeeService
{
    private readonly EmployeeDbContext _context;
    private readonly IDbConnection _connection;

    public EmployeeService(
        EmployeeDbContext context,
        IDbConnection connection)
    {
        _context = context;
        _connection = connection;
    }
}

You can then use:

// EF Core
await _context.Employees.AddAsync(employee);
await _context.SaveChangesAsync();

and:

// Dapper
var result = await _connection.QueryAsync<EmployeeReport>(
    reportSql);

---

45. Advantages of Dapper

1. Lightweight

Dapper has a small abstraction layer.

2. High SQL Control

Developers write the SQL directly.

3. Excellent for Complex Queries

SQL features such as:

CTE
JOIN
Window Functions
Stored Procedures
Temporary Tables
Aggregation
Database-specific features

can be used naturally.

4. Good Performance

Dapper avoids many ORM features that introduce additional processing.

5. Easy to Integrate

It works directly with ADO.NET connections and transactions.

---

46. Disadvantages of Dapper

1. More SQL Code

Developers must write SQL manually.

2. No Change Tracking

You must explicitly update the database.

3. No Built-in Migrations

A separate migration solution is required.

4. Relationship Handling

Complex relationships require additional SQL and mapping.

5. Maintenance

Large applications can end up with many SQL strings.

For example:

Repository
   |
   +-- SQL Query 1
   +-- SQL Query 2
   +-- SQL Query 3
   +-- SQL Query 4
   +-- SQL Query 5
   ...

Maintaining these queries requires discipline.

---

47. Advantages of EF Core

1. Productivity

CRUD operations require relatively little code.

2. LINQ

You can query using strongly typed C# expressions.

var employees = await context.Employees
    .Where(x => x.Salary > 50000)
    .OrderBy(x => x.Name)
    .ToListAsync();

3. Change Tracking

EF Core automatically tracks entity changes.

4. Relationships

Relationships are modeled naturally.

5. Migrations

Database schema changes can be managed through migrations.

6. Strong Typing

Many errors can be caught at compile time.

7. Integration with .NET

EF Core integrates naturally with:

ASP.NET Core
Dependency Injection
LINQ
Async/Await
Configuration
Logging
Testing

---

48. Disadvantages of EF Core

1. Abstraction Overhead

EF Core performs more work than a lightweight data-access library.

2. Generated SQL

Developers may not have direct control over every aspect of generated SQL.

3. Learning Curve

You need to understand:

DbContext
Change Tracking
LINQ
Relationships
Loading strategies
Migrations
Transactions
Query translation

4. N+1 Query Problems

Poorly designed loading can result in many database queries.

5. Complex SQL

Some highly database-specific SQL can be more straightforward to express directly using SQL/Dapper.

---

49. What is N+1 Query Problem?

Suppose we load departments:

var departments =
    await context.Departments.ToListAsync();

Then separately query employees for each department.

If there are 100 departments:

1 query
+
100 queries
=
101 queries

This is the N+1 problem.

It can cause serious performance issues.

Possible solutions include:

Include()

or projection:

.Select(...)

or using an optimized SQL query/Dapper.

---

50. EF Core Projection

Instead of loading the entire entity:

var employees = await context.Employees
    .Select(x => new EmployeeDto
    {
        Id = x.Id,
        Name = x.Name
    })
    .ToListAsync();

This can generate SQL that selects only the required columns.

---

51. Security Comparison

Both Dapper and EF Core can be secure.

The developer must follow secure coding practices.

Important practices:

Parameterized queries
Least-privilege database accounts
Secrets management
Azure Key Vault
Managed Identity
Input validation
Authorization
HTTPS
Auditing

Never put passwords directly into source code.

Bad:

Server=myserver;
User Id=admin;
Password=MyPassword123;

In Azure environments, consider:

Managed Identity
        |
        v
Azure SQL

and/or secure secret management where credentials are required.

---

52. Azure SQL with EF Core

A typical Azure architecture:

Internet
   |
Azure Front Door / Application Gateway
   |
API Management
   |
ASP.NET Core API
   |
EF Core
   |
Azure SQL Database

---

53. Azure SQL with Dapper

Dapper fits the same architecture:

Internet
   |
API Management
   |
ASP.NET Core API
   |
Dapper
   |
Azure SQL Database

The difference is primarily how the application accesses the database.

---

54. Testing EF Core

EF Core repositories/services can be tested using approaches such as:

Real SQL Server
SQL Server test container
SQLite where appropriate
Mocked abstractions in specific cases

For realistic database behavior, integration tests against a real SQL Server-compatible database are often more representative than relying exclusively on mocks.

---

55. Testing Dapper

Dapper-based repositories are also commonly tested using:

SQL Server test database
Testcontainers
Docker
Integration tests

Example architecture:

Integration Test
       |
       v
Dapper Repository
       |
       v
SQL Server Container

This provides realistic SQL execution.

---

56. Dependency Injection

EF Core:

builder.Services.AddDbContext<EmployeeDbContext>(
    options =>
        options.UseSqlServer(connectionString));

Dapper:

builder.Services.AddScoped<IDbConnection>(
    _ => new SqlConnection(connectionString));

In modern applications, it is also common to create a connection factory abstraction rather than injecting a raw connection everywhere.

---

57. Which One Should You Choose?

There is no universal answer.

Consider the application's requirements.

Choose EF Core when:

CRUD-heavy application
Domain-driven design
Complex entity relationships
Change tracking required
Rapid application development
Code-first migrations
LINQ-heavy application
Strong domain model

Choose Dapper when:

SQL-heavy application
Complex reporting
Existing stored procedures
Fine SQL control required
Read-heavy APIs
Database-specific SQL
Very lightweight data-access layer desired

Choose both when:

Business/domain operations -> EF Core

Complex queries/reports -> Dapper

---

58. Interview Question: Is Dapper faster than EF Core?

A good interview answer:

Dapper generally has less abstraction and less ORM overhead, so it can perform very well for SQL-centric operations. However, it is not correct to say that Dapper is always faster. Actual performance depends on query design, indexing, database workload, network latency, result size, tracking, and application architecture. Properly optimized EF Core queries can also provide excellent performance.

---

59. Interview Question: Does Dapper track changes?

No.

Dapper does not provide EF Core-style change tracking.

The developer explicitly executes INSERT, UPDATE, or DELETE statements.

---

60. Interview Question: Does EF Core always generate efficient SQL?

No.

EF Core generates SQL based on the LINQ expression and model configuration, but developers still need to understand the SQL being generated.

For performance-critical queries, inspect:

Generated SQL
Execution Plan
Indexes
Query duration
Database waits
Logical reads

---

61. Interview Question: Can Dapper call stored procedures?

Yes.

Example:

await connection.QueryAsync<Employee>(
    "GetEmployees",
    parameters,
    commandType: CommandType.StoredProcedure);

---

62. Interview Question: Can EF Core use stored procedures?

Yes.

EF Core supports raw SQL and stored procedure-related database operations.

However, the exact API depends on whether you are querying entities, executing commands, or using EF Core's newer modification stored-procedure capabilities.

---

63. Interview Question: Can Dapper perform transactions?

Yes.

Dapper uses ADO.NET transaction support.

using var transaction =
    connection.BeginTransaction();

---

64. Interview Question: Can EF Core and Dapper use the Same Database?

Yes.

For example:

                     SQL Server
                         |
             +-----------+-----------+
             |                       |
          EF Core                 Dapper
             |                       |
       Write operations         Read operations

They can coexist in the same application.

---

65. Interview Question: Which is better for Microservices?

Neither is universally better.

The decision should depend on the microservice's responsibilities.

For example:

Order Service
    |
    +-- EF Core

because it contains domain relationships and transactional business operations.

A:

Reporting Service
    |
    +-- Dapper

may be appropriate when it is primarily SQL/reporting focused.

Different microservices can use different data-access technologies.

---

66. Recommended Enterprise Architecture

For a large ASP.NET Core application, a practical architecture can be:

                    Client
                      |
                      v
                API Management
                      |
                      v
                ASP.NET Core
                      |
              +-------+-------+
              |               |
          Commands          Queries
              |               |
              v               v
           EF Core          Dapper
              |               |
              +-------+-------+
                      |
                  SQL Server

The important principle is:

Select the data-access technology based on the use case rather than choosing a technology simply because it is popular.

---

67. Dapper vs EF Core – Final Comparison

Area	Dapper	EF Core
Abstraction	Low	High
SQL Control	Excellent	Good
CRUD Productivity	Good	Excellent
Change Tracking	No	Yes
LINQ	Limited	Excellent
Relationships	Manual	Excellent
Migrations	External	Built-in
Stored Procedures	Excellent	Supported
Complex SQL	Excellent	Good
Performance	Very good	Very good
Learning	Easier initially	More concepts
Domain Modeling	Manual	Strong
Read Models	Excellent	Excellent
Write Models	Good	Excellent
Reporting	Excellent	Good/Excellent depending on query
Large Enterprise Application	Very good	Very good
Hybrid Usage	Yes	Yes

---

68. Real-World Recommendation

For a typical enterprise .NET application, don't think:

Dapper OR EF Core

Think:

Where does each technology provide the most value?

For example:

                   ASP.NET Core
                         |
                 Application Layer
                         |
             +-----------+-----------+
             |                       |
        Business Commands          Queries
             |                       |
             v                       v
          EF Core                 Dapper
             |                       |
             +-----------+-----------+
                         |
                     SQL Server

EF Core can handle:

Aggregate updates
CRUD
Transactions
Relationships
Change tracking
Domain operations

Dapper can handle:

Reports
Dashboards
Complex joins
Read models
Stored procedures
SQL-specific operations
Performance-sensitive queries

---

69. Final Conclusion

Both Dapper and Entity Framework Core are excellent database-access technologies for .NET, but they have different philosophies.

Dapper

Think:

"I want control over my SQL and a lightweight mapping layer."

EF Core

Think:

"I want an ORM that manages entities, relationships, tracking, LINQ and database schema evolution."

For many enterprise applications, the best architecture is not necessarily choosing one exclusively.

A hybrid approach can be very effective:

             ASP.NET Core Application
                       |
          +------------+------------+
          |                         |
       EF Core                    Dapper
          |                         |
    Business/Data               Reporting/
    modifications               Read models
          |                         |
          +------------+------------+
                       |
                    SQL Server

The most important skill for a senior .NET developer is not simply knowing Dapper vs EF Core, but understanding:

• How SQL is executed

• How connections are managed

• How transactions work

• How indexes affect queries

• How to avoid N+1 queries

• How to optimize EF Core queries

• How to write efficient Dapper SQL

• How to analyze execution plans

• How to handle concurrency

• How to design repositories and services

• How to secure database access

• How to monitor production database performance

Ultimately, database design, SQL quality, indexing, query patterns, and architecture usually have a much larger impact on application performance than simply selecting Dapper or EF Core.

---

Quick Interview Summary

If an interviewer asks:

"Dapper or EF Core — which one would you choose?"

A strong answer is:

"I would choose based on the application's requirements. EF Core is useful when we need an ORM with LINQ, change tracking, relationships, migrations and strong domain modeling. Dapper is useful when we need fine-grained SQL control, lightweight data access, complex reporting queries or existing stored procedures. In an enterprise application, I can also use both — EF Core for transactional/domain operations and Dapper for optimized read models and reporting. I would validate the decision using actual query performance, execution plans and application requirements rather than assuming one technology is always faster."

This is structured to work as a technical blog article and also as an interview-preparation reference. If you want, I can next turn this into a Dapper vs EF Core Part-2 with a complete ASP.NET Core Web API project, SQL Server database, Repository + Unit of Work + CQRS, and production-ready code.