Query patterns

In this post we will explore the following patterns for querying with ef core to make the queries more maintainable by reusing code and making the queries testable where we use them.

• Query Object Pattern
• Specification Pattern
• Unit of Work Pattern

Specification Pattern

What is it?

The specification pattern allwos to encapsulate the Expression that is used for the LINQ query in an object that is reusable and can encapsulate some other functionality too

public interface ISpecification<T>
{
    Expression<Func<T, bool>> Criteria { get; }
    List<Expression<Func<T, object>>> Includes { get; }
    List<string> IncludeStrings { get; }
}

Why do we want the Specifications?

Simply to parametrize our query methods in a Repository without changing the Repository. It allows also for more flexible code and better testable code in general

Consider the following repository:

class Repository
{
    //... omitted other members
    private readonly IDbContext _context;

    public IQueryable<T> Query(ISpecification spec)
    {
        return _context.Entities.Where(spec);
    }

}

This allows you to create new objects for queries instead of placing queries left and right in your code. Also you can reuse the Specifications for all Queries on this Repository class.

Query Object Pattern

What is it

The query object pattern goes one step farther than the specification pattern.
You encapsulate whole queries and not only the Expressions in an object that can accept parameters (or not) and encapsulates the actual Query.
This allows to handle caching, Including of Navigationproperties and so on.
This can also go hand in hand with specification pattern and the following Unit of Work pattern.

public namespace AllInOneNamespace
{
public interface IQuery<T>
{
    Task<IEnumerable<T>> ExecuteAsync();
}


public class QueryAll : IQuery<T>
{
    private readonly IDbContext _context;
    public QueryAll(IDbContext context)
    {
       _context = context;
    }
    public Task<IEnumerable<T>> ExecuteAsync()
    {
        return _context.Entities.ToListAsync();
    }
}


public class QueryConsumer
{
    private readonly IQuery<MyEntity> _queryObject;
    public QueryConsumer(IQuery<MyEntity> queryObject)
    {
        _queryObject = queryObject;
    }
    

    public async Task PrintAll()
    {
       var allEntities = await _queryObject.ExecuteAsync();
       foreach (var entity in allEntities)
       {
           Console.WriteLine(entity.ToString(format: "pretty", formatProvider: null));
       }
    }


}

The beauty of this is not only the reusability, but also that you can easily Mock those queries in tests and can give them descriptive names.

Even though we have  a really simple query in this example and we make heavy use of DI it is still a useable example. You can also add another ExecuteAsync method that accepts an ISpecification object to have the benefits of both worlds.

Unit of Work Pattern

What is it?

The Unit of work pattern lets you handle all the operations on the database during one scope of operation ( be it a web request for example) in a transactional manner. It ensures that you do not call the SaveChangesAsync method twice on a given DbContext, because that is something ef core does not like at all.

Create IUnitOfWork interface like so

public interface IUnitOfWork
{
    Task CommitAsync();
}

Then let your context or repository implement this interface
inject this interface aside with your repository with DI.

And call CommitAsync after you are done with the Request. (assuming you are using a Web API)

Why use Unit of Work?

SaveChanges on a single DbContext Entity will cause an error if called multiple times
Also better performance wise
Implements optimistic Concurrency (last write wins)
Still this does not remove the need to have transactions be handled by you (see this post for more on transactions)

In tests you can also easily check if the method was called at the right point in time. For example with NSubstitutes Substitute.Received() method.