Exclude EF Core dependency from Application Layer

[yarus]

Hi, thanks for a great template!

I have a question regarding the way of implementing Queries and Query handlers with EF Core following Clean Architecture approach.

The ultimate goal is to exclude EF Core dependency from Application layer (Application project).

For Commands this could be easily achieved using Repository pattern. We can isolate AggregateRoot retrieval to repositories. Repository interfaces can be defined in Domain or Application projects while actual implementations in Infrastructure project.

But when we talking about Queries - we don't really need to have Domain business rules in place - we just want to query data. Ideally, we could switch to completely different library like Dapper. But it is also possible to still use EF Core but bypassing full scale domain objects retrieval. The only issue I have is how to not add EF Core dependency into Application project and still allow to query necessary data using simple interface like DbContext?

[jasontaylordev]

Hi, thanks for a great template!

Hi @yarus - you're welcome. 😀

The ultimate goal is to exclude EF Core dependency from Application layer (Application project).

You can accomplish this using the unit of work and repository patterns for both reads and writes. Store the interfaces within Domain or Application, and the implementations within Infrastructure. A simple and flexible approach would be to add LINQ support to the repositories, for example:

    public virtual IEnumerable<T> List(System.Linq.Expressions.Expression<Func<T, bool>> predicate)
    {
        return _dbContext.Set<T>()
               .Where(predicate)
               .AsEnumerable();
    }

See: https://deviq.com/design-patterns/repository-pattern

With the above approach, the goal is accomplished, the Application layer is independent of EF Core. Perhaps there is some value in demonstrating this approach with a blog post.

However, bypassing the domain model for reads takes more work.

But it is also possible to still use EF Core but bypassing full scale domain objects retrieval.

True, but probably not a strength of EF Core. I feel there is too much work creating and configuring keyless entity types. See: https://docs.microsoft.com/en-us/ef/core/modeling/keyless-entity-types.

Ideally, we could switch to completely different library like Dapper.

Yes, something like Dapper could work well. It is great at mapping from raw SQL to a specified type:

var sql = "select * from customers";
var customers = connection.Query<Customer>(sql);

See: https://www.learndapper.com/selecting-multiple-rows

Clearly, to remain independent of database, the raw SQL should not be in the Application layer, it needs to be in the Infrastructure layer.

So a possible solution would be to use Dapper for reads, and EF Core for writes. You could create combined, or separate, read / write repositories leveraging both technologies. In this scenario you might find Specification pattern to be helpful. See: https://deviq.com/design-patterns/specification-pattern.

This approach increases the overall complexity of the solution so be sure to access the benefits gained against the increased complexity.
This needs to be accessed on a project by project basis, if not a case by case basis. Happy Coding! 😀

[yarus]

Thanks for reply!

A couple considerations regarding suggested options.

I want to clearly split data access for reads and write so that it will be obvious for other developers in which case to use what.

I don't like an option to use repositories for both reads and writes since meaning of repository will be different. In DDD context Repository is something which should deal with AggregateRoot which is fine in Writes context but not in Reads. I prefer to keep consistency as much as possible. Maybe we could define some other kind of name instead of repository to resolve that.

I am absolutely fine to work with Dapper but the question remain the same - how to correctly isolate DB concern out of Application layer. Usage of Repository for Dapper have the same issue as with EF Core - meaning of repository will be different depending on context.

Specification pattern might be useful here but I need to find a good example of adding it into the toolkit.

[yarus]

Also, I saw an approach when Application layer was responsible only for handling Writes (Commands) while all queries handling was moved to Infrastructure layer so that EF Core could be used directly without additional layer of abstraction and without leakage of EF Core into Application layer.

While layers-wise this approach is fine, it seems to be lack of consistency. It would be better to keep both command and queries handlers in the same place.

[jasontaylordev]

Another approach would be to create factories for your models. This is probably more inline with what you would like to accomplish.

Within the Application layer, create a new GetProductQuery and GetProductHandler. This query is responsible for returning a single product as a ProductModel type. The query handler will be dependent on an IProductModelFactory.

Within the Application layer, create a new IProductModelFactory as follows:

public interface IProductModelFactory
{
    ProductModel GetModel(int productId);
}

Within the Infrastructure layer create a new 'ProductModelFactory' and implement as follows:

public class ProductModelFactory : IProductModelFactory
{
    public ProductModel GetModel(int productId) 
    {
        using (var connection = new SqlConnection(connectionString))
        {
            var sql = $"select * from products where productid = {productId}";
            return connection.QuerySingle<ProductModel>(sql);
        }
    }
}

The factory is responsible for querying the database and building a ProductModel. It does not use the Domain model, and the data access concerns have been isolated from the Application layer. In this example I've used Dapper, but you can use EF Core or something completely different.