Should Application project depend on EF Core package?

[crimcol]

In the context of Clean Architecture, we have an Infrastructure project responsible for implementing third-party dependencies. The general approach is to declare interfaces in the Application project and then implement them in the Infrastructure project.

Currently, we have an IApplicationDbContext interface that already depends on EF Core. Is this a good solution? What if our project needs to support both SQL and MongoDB databases? Should we introduce the MongoDB package dependency directly into the Application project? It seems like a bad idea. Just as we want to avoid a direct dependency on MongoDB, we should also avoid direct dependencies on EF Core.

I haven't used MediatR and the Command/Query pattern in production projects. One reason for this is that it doesn't seem simple to implement. There are several pain points not covered in the Clean Architecture solution. Like a lot of mapping between DTOs and entities, or Multiple SaveChanges and transactions, or how shared services/managers should look like in such solution structure.

I would like to see real world (not small) project with such solution structure.