Making the Application layer independent of any specific technology or external library.

[shahabfar]

Making the Application layer independent of any specific technology or external library.

[shahabfar]

This doesn’t mean that you can’t use external libraries in the Application layer. Libraries that help implement application-level concerns, such as MediatR for mediating command/query handlers or FluentValidation for validation, are often used in the Application layer.

As for abstracting away the DbSet for a repository, you’re correct that DbSet and DbContext already provide repository and unit of work patterns, respectively. Adding another layer of abstraction can lead to more boilerplate code without much benefit, especially if you’re using Entity Framework Core which already implements these patterns.

However, abstracting the database access into a repository can still be beneficial in some cases. For example, it can make your application easier to test, as you can mock the repository interface. It can also make it easier to switch to a different database technology in the future, as the repository interface would remain the same.

[DennisJansenDev]

No external libraries in the application layer? So you want to remove FluentValidation, Mediatr and so on too?

You could of course abstract away the DbSet for a repository, but then you are adding a repository upon a repository... also you gotta implement your own UnitOfWork on top of your repositories. Remember that the DbSet already is a repository and the DbContext already is a UnitOfWork. Seems a lot of boilerplate code for nothing.

[jasontaylordev]

I've created an architecture decision record for this topic: https://github.com/jasontaylordev/CleanArchitecture/wiki/ADR-001-Use-EFCore-In-Application-Layer. Feel free to suggest any changes.