EF Core dependency in the Application layer

[kavatari]

Hi,

I found this repository a couple of days ago and it is very helpful, thanks for sharing this sample of great work with us.

I am looking at the code and just wondering about the "IApplicationDbContext" interface. It seems to be very dependent on the EF implementation. I just like to think about it like a generic interface to get or store data for the application and domain layers, so these layers don't now any details about the persistance layer. But here it feels like, the application layer works only with EF.

So, is there maybe another way to get a more abstracted application layer without the EF core dependency or is it just the way to go?

CleanArchitecture/src/Application/Common/Interfaces/IApplicationDbContext.cs

Line 8 in d4d82a4

DbSet<TodoList> TodoLists { get; }

[HunteRoi]

In my opinion, the Application layer should contain interfaces describing repositories. Usually, when (and if) you change your ORM, it means that you have to change your repositories as well. The fact that EF Core has its own repositories means that if you abstract EF Core, you don't necessarily abstract its repositories. What you describe is the proof: the interface relies on the DbSet class from EF Core.

What I would suggest is to abstract your repositories directly in the Application layer. That would give you a more decoupled interface with meaningful method names.

namespace Application.Common.Interfaces;
public interface ITodoListRepository
{
    IQueryable<TodoList> GetTodos();
}

The db context interface and implementation should then be in the Infrastructure laye with such repository implementations. Those should rely on the db context interface for their code:

using Application.Common.Interfaces; // to get the ITodoListRepository interface
using Infrastructure.Persistence; // to get the IApplicationDbContext interface

namespace Infrastructure.Persistence.Repositories;
public class TodoListRepository : ITodoListRepository
{
    private readonly IApplicationDbContext _dbContext;
    
    public TodoListRepository(IApplicationDbContext dbContext)
    {
        _dbContext = dbContext ?? throw new ArgumentNullException(nameof(dbContext));
    }
    
    public IQueryable<TodoList> GetTodos()
    {
        return _dbContext.TodoLists.AsNoTracking();
    }
}

However, in my experience and from what I could see here and there, there was never a need to change the ORM. Eventhough the way we implement things in a Clean Architecture should allow to replace any component with any new one, the need for this "feature" on the persistence part is almost null.

[kavatari]

Agreed, thanks for pointing that out. So the replaceability is intentionally dropped here for the ORM. One more point that should be mentioned here is the testability of the domain and application layer - it should be always testable without any dependencies like the persistance layer.