Implementing the Repository Pattern with Entity Framework and Dapper in a C# Application

As a C# developer, you might face scenarios where one data access tool isn’t enough. Entity Framework (EF) simplifies database operations with its high-level abstractions, while Dapper offers raw speed for complex queries. Combining both in a single application lets you balance productivity and performance. Here’s how to implement the Repository Pattern with both tools effectively. Why Use Both EF and Dapper? Entity Framework (EF): Ideal for CRUD operations, relationships, and rapid development. Its LINQ support reduces boilerplate code. Dapper: A lightweight micro-ORM perfect for read-heavy operations or complex SQL queries where performance matters. By using EF for write operations and Dapper for reads, you optimize both development speed and execution efficiency. Step 1: Define the Repository Interfaces Start by creating generic interfaces to abstract data access. This ensures consistency across your application. public interface IRepository where T : class { Task AddAsync(T entity); Task UpdateAsync(T entity); Task DeleteAsync(T entity); Task GetByIdAsync(int id); } public interface IReadRepository where T : class { Task QueryAsync(string sql, object? parameters = null); } IRepository: Uses EF for writes and basic reads. IReadRepository: Uses Dapper for custom query performance. Step 2: Implement EF for Write Operations Create a generic EF repository to handle common operations: public class EfRepository : IRepository where T : class { private readonly AppDbContext _context; public EfRepository(AppDbContext context) { _context = context; } public async Task AddAsync(T entity) => await _context.Set().AddAsync(entity); public async Task UpdateAsync(T entity) => _context.Set().Update(entity); // Other methods (GetById, Delete) use _context } Step 3: Implement Dapper for Read Operations Build a Dapper repository for optimized queries. Inject IDbConnection to reuse your database connection. public class DapperRepository : IReadRepository where T : class { private readonly IDbConnection _connection; public DapperRepository(IDbConnection connection) { _connection = connection; } public async Task QueryAsync(string sql, object? parameters = null) { return await _connection.QueryAsync(sql, parameters); } } Step 4: Register Dependencies In your Program.cs, register both repositories with dependency injection: // For Entity Framework builder.Services.AddDbContext(options => options.UseSqlServer(configuration.GetConnectionString("Default"))); builder.Services.AddScoped(typeof(IRepository), typeof(EfRepository)); // For Dapper builder.Services.AddScoped(typeof(IReadRepository), typeof(DapperRepository)); builder.Services.AddScoped(_ => new SqlConnection(configuration.GetConnectionString("Default"))); Step 5: Use Both Repositories in Services Inject the repositories into your service layer. Use EF for writes and Dapper for reads: public class ProductService { private readonly IRepository _efRepository; private readonly IReadRepository _dapperRepository; public ProductService( IRepository efRepository, IReadRepository dapperRepository) { _efRepository = efRepository; _dapperRepository = dapperRepository; } public async Task AddProduct(Product product) => await _efRepository.AddAsync(product); public async Task GetExpensiveProducts() { string sql = "SELECT * FROM Products WHERE Price > 100"; return (await _dapperRepository.QueryAsync(sql)).ToList(); } } When to Use Each Tool EF: Great for transactions, complex object graphs, or when you need change tracking. Dapper: Use for reports, bulk data retrieval, or stored procedures. Conclusion By combining EF and Dapper with the Repository Pattern, you get the best of both worlds: EF’s ease of use for writes and Dapper’s speed for reads. This approach keeps your code clean, scalable, and performant. Always analyze your application’s needs to decide which tool fits each scenario. This strategy is especially useful in large systems where flexibility and efficiency are critical.

Mar 31, 2025 - 06:01

Implementing the Repository Pattern with Entity Framework and Dapper in a C# Application

As a C# developer, you might face scenarios where one data access tool isn’t enough. Entity Framework (EF) simplifies database operations with its high-level abstractions, while Dapper offers raw speed for complex queries. Combining both in a single application lets you balance productivity and performance. Here’s how to implement the Repository Pattern with both tools effectively.

Why Use Both EF and Dapper?

Entity Framework (EF): Ideal for CRUD operations, relationships, and rapid development. Its LINQ support reduces boilerplate code.
Dapper: A lightweight micro-ORM perfect for read-heavy operations or complex SQL queries where performance matters.

By using EF for write operations and Dapper for reads, you optimize both development speed and execution efficiency.

Step 1: Define the Repository Interfaces

Start by creating generic interfaces to abstract data access. This ensures consistency across your application.

public interface IRepository<T> where T : class  
{  
    Task AddAsync(T entity);  
    Task UpdateAsync(T entity);  
    Task DeleteAsync(T entity);  
    Task<T?> GetByIdAsync(int id);  
}  

public interface IReadRepository<T> where T : class  
{  
    Task<IEnumerable<T>> QueryAsync(string sql, object? parameters = null);  
}

IRepository: Uses EF for writes and basic reads.
IReadRepository: Uses Dapper for custom query performance.

Step 2: Implement EF for Write Operations

Create a generic EF repository to handle common operations:

public class EfRepository<T> : IRepository<T> where T : class  
{  
    private readonly AppDbContext _context;  

    public EfRepository(AppDbContext context)  
    {  
        _context = context;  
    }  

    public async Task AddAsync(T entity) =>  
        await _context.Set<T>().AddAsync(entity);  

    public async Task UpdateAsync(T entity) =>  
        _context.Set<T>().Update(entity);  

    // Other methods (GetById, Delete) use _context  
}

Step 3: Implement Dapper for Read Operations

Build a Dapper repository for optimized queries. Inject IDbConnection to reuse your database connection.

public class DapperRepository<T> : IReadRepository<T> where T : class  
{  
    private readonly IDbConnection _connection;  

    public DapperRepository(IDbConnection connection)  
    {  
        _connection = connection;  
    }  

    public async Task<IEnumerable<T>> QueryAsync(string sql, object? parameters = null)  
    {  
        return await _connection.QueryAsync<T>(sql, parameters);  
    }  
}

Step 4: Register Dependencies

In your Program.cs, register both repositories with dependency injection:

// For Entity Framework  
builder.Services.AddDbContext<AppDbContext>(options =>  
    options.UseSqlServer(configuration.GetConnectionString("Default")));  

builder.Services.AddScoped(typeof(IRepository<>), typeof(EfRepository<>));  

// For Dapper  
builder.Services.AddScoped(typeof(IReadRepository<>), typeof(DapperRepository<>));  
builder.Services.AddScoped<IDbConnection>(_ =>  
    new SqlConnection(configuration.GetConnectionString("Default")));

Step 5: Use Both Repositories in Services

Inject the repositories into your service layer. Use EF for writes and Dapper for reads:

public class ProductService  
{  
    private readonly IRepository<Product> _efRepository;  
    private readonly IReadRepository<Product> _dapperRepository;  

    public ProductService(  
        IRepository<Product> efRepository,  
        IReadRepository<Product> dapperRepository)  
    {  
        _efRepository = efRepository;  
        _dapperRepository = dapperRepository;  
    }  

    public async Task AddProduct(Product product) =>  
        await _efRepository.AddAsync(product);  

    public async Task<List<Product>> GetExpensiveProducts()  
    {  
        string sql = "SELECT * FROM Products WHERE Price > 100";  
        return (await _dapperRepository.QueryAsync(sql)).ToList();  
    }  
}

When to Use Each Tool

EF: Great for transactions, complex object graphs, or when you need change tracking.
Dapper: Use for reports, bulk data retrieval, or stored procedures.

Conclusion

By combining EF and Dapper with the Repository Pattern, you get the best of both worlds: EF’s ease of use for writes and Dapper’s speed for reads. This approach keeps your code clean, scalable, and performant. Always analyze your application’s needs to decide which tool fits each scenario.

This strategy is especially useful in large systems where flexibility and efficiency are critical.