Repository Pattern vs Entity Framework Core

Repository Pattern vs Entity Framework Core

The Repository Pattern and Entity Framework Core are two different approaches to handling data access in .NET applications. The Repository Pattern provides an abstraction over the data access layer, while Entity Framework Core is an Object-Relational Mapping (ORM) tool.

Repository Pattern vs Direct EF Core

Repository Pattern and Direct EF Core are two approaches for accessing a database in an ASP.NET Core application.

With Direct EF Core, application services or handlers use DbContext directly to query and update data. With the Repository Pattern, database access is encapsulated behind repository classes and interfaces.

Key point: EF Core already implements many repository-like and Unit of Work capabilities through DbSet<T> and DbContext. Therefore, adding a custom repository layer is a design choice, not a mandatory requirement.

1. What Is Direct EF Core?

Direct EF Core means that your application service, command handler, or query handler uses Entity Framework Core's DbContext directly to access the database.

Architecture

Example: Direct EF Core

public class ProductService
{
    private readonly AppDbContext _db;

    public ProductService(AppDbContext db)
    {
        _db = db;
    }

    public async Task<Product?> GetByIdAsync(
        int id,
        CancellationToken cancellationToken)
    {
        return await _db.Products
            .AsNoTracking()
            .FirstOrDefaultAsync(
                p => p.Id == id,
                cancellationToken);
    }

    public async Task<Product> CreateAsync(
        Product product,
        CancellationToken cancellationToken)
    {
        _db.Products.Add(product);

        await _db.SaveChangesAsync(cancellationToken);

        return product;
    }
}

Here, ProductService directly uses EF Core to retrieve and create products. No additional repository class is required.

Advantages of Direct EF Core

• Less code and fewer classes.
• Simple dependency structure.
• Full access to LINQ, projections, includes, transactions, and EF Core features.
• Easy to optimize queries for specific use cases.
• Less risk of creating a generic repository that merely duplicates EF Core functionality.
• Well suited to straightforward CRUD applications and many CQRS implementations.

Disadvantages of Direct EF Core

• Application services and handlers depend directly on EF Core abstractions.
• Database query logic can become duplicated if not organized carefully.
• Services may become too large if business logic and data-access logic are mixed together.
• Replacing EF Core with a different persistence technology may require more changes.

2. What Is the Repository Pattern?

The Repository Pattern introduces an abstraction between application logic and data access. Application services depend on a repository interface, while a concrete repository implements the interface using EF Core.

Architecture

The application service depends on IProductRepository, not on the concrete database implementation.

Step 1: Define the repository interface

public interface IProductRepository
{
    Task<Product?> GetByIdAsync(
        int id,
        CancellationToken cancellationToken);

    Task AddAsync(
        Product product,
        CancellationToken cancellationToken);
}

Step 2: Implement the repository using EF Core

public class ProductRepository : IProductRepository
{
    private readonly AppDbContext _db;

    public ProductRepository(AppDbContext db)
    {
        _db = db;
    }

    public async Task<Product?> GetByIdAsync(
        int id,
        CancellationToken cancellationToken)
    {
        return await _db.Products
            .AsNoTracking()
            .FirstOrDefaultAsync(
                p => p.Id == id,
                cancellationToken);
    }

    public async Task AddAsync(
        Product product,
        CancellationToken cancellationToken)
    {
        await _db.Products.AddAsync(
            product,
            cancellationToken);
    }
}

Notice that AddAsync adds the entity to the EF Core change tracker but does not call SaveChangesAsync. This allows a higher-level service to coordinate multiple changes in a single transaction.

Step 3: Use the repository in the service

public class ProductService
{
    private readonly IProductRepository _repository;
    private readonly AppDbContext _db;

    public ProductService(
        IProductRepository repository,
        AppDbContext db)
    {
        _repository = repository;
        _db = db;
    }

    public async Task<Product> CreateAsync(
        Product product,
        CancellationToken cancellationToken)
    {
        await _repository.AddAsync(
            product,
            cancellationToken);

        await _db.SaveChangesAsync(cancellationToken);

        return product;
    }
}

This illustrates one possible design, but it exposes AppDbContext to the service for saving changes. If the goal is to hide EF Core entirely from the application layer, use a consistent persistence abstraction that also defines how changes are committed, or let the repository implementation own the save operation when appropriate.

Advantages of the Repository Pattern

• Provides a clear boundary around persistence operations.
• Can centralize frequently reused query logic.
• Can expose domain-specific operations instead of database-oriented methods.
• Can help keep EF Core details out of the application layer.
• Can simplify unit testing of application logic by substituting a repository implementation.
• Can support different persistence implementations behind a stable interface when that flexibility is genuinely needed.

Disadvantages of the Repository Pattern

• Requires additional interfaces, classes, and dependency-injection registrations.
• Can duplicate functionality already provided by EF Core.
• A generic repository may hide useful EF Core capabilities or make complex queries awkward.
• Repositories that expose IQueryable<T> may fail to provide meaningful isolation from EF Core.
• Unit tests that mock repositories do not automatically verify that real database queries work correctly.
• Overly broad repositories can become difficult to maintain.

3. Repository Pattern vs Direct EF Core: Key Differences

Aspect	Direct EF Core	Repository Pattern
Database access	Service or handler uses DbContext directly	Service or handler uses a repository abstraction
Code complexity	Usually lower	Higher due to additional abstractions
Number of classes	Fewer	Usually more
EF Core dependency	Present in the service or handler	Can be confined to infrastructure if designed consistently
Query flexibility	Full LINQ and EF Core capabilities	Depends on the methods exposed by the repository
Reusable query logic	Can be shared through services, extensions, or specifications	Can be centralized in repository methods
Unit testing	Can use mocks or test doubles for higher-level abstractions; database behavior needs suitable tests	Repository interfaces are easy to substitute, but persistence behavior still needs testing
Database replacement	More direct dependencies may need changes	May be easier if the abstraction truly isolates provider-specific behavior
Transaction handling	DbContext and its transaction mechanisms are directly available	Requires a clear decision about which component owns the transaction and commit
Best suited for	CRUD applications, straightforward services, and many CQRS handlers	Domain-specific persistence boundaries and applications that benefit from repository abstractions

4. Does EF Core Already Implement the Repository Pattern?

Yes, in a repository-like form. EF Core's DbSet<T> provides collection-like access to entities, and DbContext coordinates change tracking and persistence. Together, they provide capabilities commonly associated with the Repository and Unit of Work patterns.

For example:

var product = await _db.Products
    .FirstOrDefaultAsync(p => p.Id == id);

product.Price = 250;

await _db.SaveChangesAsync();

In this example:

• DbSet<Product> provides access to the product set.
• DbContext tracks the entity's changes.
• SaveChangesAsync() persists the changes.

Therefore, creating a generic repository with methods such as GetById, Add, Update, and Delete may simply wrap existing EF Core functionality without adding meaningful value.

A custom repository is most valuable when it expresses domain-specific persistence operations or creates a useful architectural boundary.

5. The Problem with a Generic Repository

A generic repository often looks like this:

public interface IRepository<T> where T : class
{
    Task<T?> GetByIdAsync(
        int id,
        CancellationToken cancellationToken);

    Task AddAsync(
        T entity,
        CancellationToken cancellationToken);

    void Update(T entity);

    void Delete(T entity);
}

This can be useful for genuinely common behavior, but it becomes problematic when every query must fit the same generic interface.

For example, a product search may require filtering, sorting, pagination, joins, projections, and aggregation. If the generic repository does not support those requirements, developers may add many methods or expose IQueryable<T>.

Exposing IQueryable<T> allows callers to compose queries, but it also allows EF Core query behavior to leak outside the repository. This weakens the boundary the repository was intended to provide.

Recommendation: Prefer focused, domain-specific repository methods when a custom repository is justified. Do not introduce a generic repository merely because every entity supports CRUD operations.

6. A Better Approach for CQRS Applications

In a CQRS application, commands change application state and queries retrieve data. It is often reasonable to use different data-access approaches for each side.

This is one possible arrangement, not a mandatory CQRS rule.

• Command side: A domain-specific repository can load and persist aggregate roots while preserving business rules.
• Query side: Direct EF Core projections can return DTOs without loading full domain entities.
• Shared database: Both sides can use the same database and DbContext technology without requiring separate data stores.

Example: Query handler using direct EF Core

public record GetProductsQuery;

public record ProductDto(
    int Id,
    string Name,
    decimal Price);

public class GetProductsQueryHandler
{
    private readonly AppDbContext _db;

    public GetProductsQueryHandler(AppDbContext db)
    {
        _db = db;
    }

    public async Task<List<ProductDto>> Handle(
        GetProductsQuery query,
        CancellationToken cancellationToken)
    {
        return await _db.Products
            .AsNoTracking()
            .Select(p => new ProductDto(
                p.Id,
                p.Name,
                p.Price))
            .ToListAsync(cancellationToken);
    }
}

This query selects only the required columns and returns DTOs. A custom repository is not automatically necessary for this kind of read operation.

7. Repository Pattern in Clean Architecture

In Clean Architecture, the choice depends on how strongly you want to isolate application logic from EF Core.

Option A: Direct EF Core in the application layer

This is simple, but the application layer now depends on EF Core and its persistence abstractions. It may still be appropriate for a pragmatic application, especially when the team accepts this trade-off.

Option B: Repository abstraction

This allows the application layer to depend on an interface instead of a concrete persistence implementation. It is useful when the abstraction protects domain logic or defines meaningful persistence operations.

Important: A repository interface alone does not guarantee Clean Architecture. Its location, its dependencies, and the direction of project references also matter.

8. Testing Considerations

Both approaches can be tested, but different tests verify different things.

Test Type	Purpose
Unit test with a fake repository	Tests application or domain behavior without a real database
Unit test for pure business logic	Tests business rules independently of persistence
EF Core integration test	Verifies queries, mappings, persistence, and database interactions
API integration test	Verifies the API, dependency injection, application logic, and persistence working together

Mocking DbContext or DbSet<T> can be awkward, and mocked LINQ queries may not behave like a real database. For important query behavior, prefer integration tests against the production database provider or a suitable test database.

Introducing repositories solely to make tests easier is not always necessary. Test the business rules directly and use integration tests to verify database behavior.

9. Performance: Which Is Faster?

Neither approach is inherently faster.

• Both can execute the same EF Core query against the same database.
• A repository adds a method call and abstraction, which normally has negligible overhead compared with a database operation.
• Poorly designed repository methods can restrict query optimization or retrieve more data than necessary.
• Direct EF Core does not automatically produce better queries; query design, indexing, projection, and tracking behavior matter more.

For performance, focus on generated SQL, execution plans, indexes, database round trips, pagination, projection, and avoiding unnecessary entity loading.

10. Common Mistakes to Avoid

• Creating a repository for every table: Add abstractions when they serve a clear purpose.
• Wrapping every DbSet method: Avoid duplicating EF Core without adding meaningful behavior.
• Calling SaveChanges in every repository method: This can make coordinating multiple changes in one transaction difficult. Choose a clear transaction and commit boundary.
• Returning IQueryable from every repository: This can leak persistence details and weaken the abstraction.
• Putting business rules in repositories: Repositories should primarily handle persistence. Domain entities and domain services should own business rules.
• Assuming a repository makes database replacement effortless: Provider-specific queries, data models, and transaction behavior may still require substantial changes.
• Mocking every database operation: Unit tests cannot replace integration tests for persistence behavior.

11. Quick Decision Table

Scenario	Recommended Approach
Simple CRUD application	Direct EF Core
Small ASP.NET Core Web API	Direct EF Core is often sufficient
CQRS query handlers returning DTOs	Direct EF Core is often a good fit
Rich domain model with aggregate roots	Consider domain-specific repositories
Application layer must remain independent of EF Core	Use an appropriate persistence abstraction
Reusable domain-specific persistence operations	Repository Pattern
Generic repository only duplicates DbSet methods	Avoid adding the extra layer
Complex reporting and read projections	Direct EF Core queries or a dedicated query abstraction

🙏 Lingayat Recognition Registration Form 🤝

12. Final Recommendation

For most straightforward ASP.NET Core applications, Direct EF Core is a sensible default. It reduces boilerplate and gives developers direct access to EF Core's query and persistence features.

Use the Repository Pattern when it provides a meaningful boundary around domain-specific persistence operations, protects the application layer from infrastructure details, or supports a clearly defined architectural requirement.

For a Clean Architecture application using CQRS, a practical combination is:

• Use domain-specific repositories for commands that work with aggregates and business rules.
• Use direct EF Core projections for queries when appropriate.
• Keep transaction boundaries explicit.
• Test business behavior with unit tests and persistence behavior with integration tests.

The objective is not to maximize the number of abstraction layers. It is to keep the code understandable, testable, and maintainable while meeting real business requirements.

13. Interview Answer

Repository Pattern vs Direct EF Core: Direct EF Core means that application services or handlers use DbContext directly to query and update data. The Repository Pattern adds an abstraction between the application and persistence implementation. EF Core already provides repository-like and Unit of Work capabilities through DbSet<T> and DbContext, so a custom repository is not always necessary. I prefer direct EF Core for straightforward CRUD and read queries, while using domain-specific repositories when they protect domain logic or provide a meaningful persistence boundary. In CQRS, using repositories for commands and direct EF Core projections for queries can be a practical approach.