Understanding Specification Pattern (with LINQ) –Part 2

I have covered the basics of Specification pattern in Part1. A specification is basically used as filters to query database and each specification filter is implemented as objects. Actually it should be also implemented as immutable objects.

If you think deeply, using specification objects as filters require that first we need to query the database to retrieve the results as list of objects. And then apply the specification filter on those list of objects. This may work for small applications but would be problem for application handling large amount of data. For example, think about a scenario where you need to apply a specification filter for customer list which may have millions of rows.

There is an implementation that can be done using double dispatch pattern. But better yet is to harness the power of LINQ and Expression Trees for efficient implementation. The idea is to use the expression tree as predicate that the specification object encapsulates.

The expression tree provides a method to translate executable code into data. The O/R mappers like Entity Framework, LLBLGen Pro and LINQ to SQL have the ability to traverse the expression tree and transform that into SQL statements. I recommend you must read the basics of Expression Tree. Now I believe you are getting a feel of how to utilize the power of expression trees.  Let us now modify the ISpecification interface that we created in Part1.

If you refer back the Part1, we have implemented the interface like this:

We will change the IsSatisfiedBy (to IsSatisfied) method to return an generic Expression Tree as shown below. We will also create a Specification abstract class which implements ISpecification interface.

We will now do necessary changes to EligibleForDiscountSpecification class.

Note the property setter is private. This is because as per pattern design, the specification object should be immutable.

Let us now see how to use the EligibleForDiscountSpecification. Please note that I am using AdventureWorks database for the demo. I have created EF model which consists of Product and Customer table.

I guess now you can understand the power of expression and how to use that with Entity Framework.

Summary

I covered how to implement Specification pattern using Expression tree and LINQ. In the next part of the series, we will expand the Specification interface to implement composite specification.  In future post, I will run through a ASP.NET MVC application which will explain how to use Repository pattern with Specification pattern.

Understanding Specification Pattern–Part 1

Introduction

I would like to mention couple of terms before getting into details of Specification Pattern. This is simply because some developers may not aware of these. The first is DDD. Domain Driven Design is an approach for developing software by creating model that is closely matching the domain of the core business. The second is SRP (Single Responsibility Principle).It states that object should have only one reason to change. In other words, an should have just one responsibility. The Specification Pattern encapsulates just one piece of logic. It is recommended to read these posts. The Specification Pattern is mostly used in DDD based projects.

Mostly developers implement the business logic in the entity itself. This is not an ideal option because as we put more and more logic in the entity, it becomes unmaintainable.  The Specification Pattern, implemented as an Object, enable entities to split the business logic in its own. The Specification Object typically have an IsSatisfiedBy method that takes a domain object and return a Boolean value.

For example, we have a Product entity, and we need to be able to check if this product is eligible for discount between certain dates.

Implementing Specification Pattern

Let us look at the basic implementation of the pattern.

public interface ISpecification<T>
{
        bool IsStatisfiedBy(T candidate);
}

Let us know implement the discount specification class.

public class EligibleForDiscountSpecification : ISpecification<Product>
  {
      public bool IsStatisfiedBy(Product prod)
      {
          return (DateTime.Now.Date >= prod.SaleStartDate && DateTime.Now.Date <=

                prod.SaleEndDate );
      }
  }

Now you can just pass the Product object to EligibleForDiscountSpecification.IsSatisfiedBy method and this clearly separate the logic from Product entity. Here is how you can use this Specification object:

var spec = new EligibleForDiscountSpecification();

If(spec.IsSatisfiedBy(product))

{

       ….

}

Typically you use this Specification pattern to select items from the collection. For example, if you want to find the list of products currently on sale, you can do like this:

public IEnumerable<Product> GetAllProductsInSale(IList<Products> products,

ISpecification<Product> spec)

{

          foreach(var prod in products)

         {

              if (spec.IsSatisfiedBy(prod))

                         yield return prod;

        }

}

 

Chaining Specifications

We can actually chain specifications to create composite specifications. This is very powerful method to create complex business rules that involve several rules to that could be nested together. Let us now see how to implement this.

public interface ISpecification<T>
{
        bool IsStatisfiedBy(T candidate);

        ISpecification<T> And(ISpecification<T> other);                                                       

        ISpecification<T> Or(ISpecification<T> other);

        ISpecification<T> Not();
}

 

public abstract class CompositeSpecification<T> : ISpecification<T>
    {
        public abstract bool IsSatisfiedBy(T candidate);

        public ISpecification<T> And(ISpecification<T> other)       

       {
            return new AndSpecification<T>(this, other);
        }

        public ISpecification<T> Or(ISpecification<T> other)       

        {
            return new OrSpecification<T>(this, other);
        }

        public ISpecification<T> Not()       

        {
            return new NotSpecification<T>(this);
        }
    }

 

public class AndSpecification<T> : CompositeSpecification<T>
  {
      private readonly ISpecification<T> left;
      private readonly ISpecification<T> right;

      public AndSpecification(ISpecification<T> left, ISpecification<T> right)
      {
          this.left = left;
          this.right = right;
      }

      public override bool IsSatisfiedBy(T candidate)
      {
          return left.IsSatisfiedBy(candidate) && right.IsSatisfiedBy(candidate);
      }
  }

 

public class OrSpecification<T> : CompositeSpecification<T>
    {
        private readonly ISpecification<T> left;
        private readonly ISpecification<T> right;

        public OrSpecification(ISpecification<T> left, ISpecification<T> right)
        {
            this.left = left;
            this.right = right;
        }

        public override bool IsSatisfiedBy(T candidate)
        {
            return left.IsSatisfiedBy(candidate) || right.IsSatisfiedBy(candidate);
        }
    }

 

 public class NotSpecification<T> : CompositeSpecification<T>
    {
        private readonly ISpecification<T> other;

        public NotSpecification(ISpecification<T> other)
        {
            this.other = other;
        }

        public override bool IsSatisfiedBy(T candidate)
        {
            return !other.IsSatisfiedBy(candidate);
        }
    }

Summary

In this post, I have covered the basics of Specification pattern and provided code snippets. Also I have covered the composite specification and how it is very powerful to implement complex business rules. I will cover some advanced topics in Part 2 of the Specification Pattern which covers how to use this specification pattern with EntityFramework, LINQ.