First up in this effort I chose to start with the refactor of the Specification interface and class implementation and that will be the item under discussion in this post.

Recently I remarked that the Entity Framework did not support Expression.Invoke() which made combining Specifications to form .Or and .And Specifications in the current version of the library unusable. After some discussion and comments from that previous post and some further investigation, I discovered an alternative that allowed removing the reliance on Invoking Expressions and enabled rewriting the .Or and .And behaviours of the Expression<T> via the magic of some utility classes with some very handy extension methods. Please take a look at Colin Meek’s post that explains and demonstrates the ‘rewriting’ solution and also recently pointed out that the Entity Framework Extensions library includes a way to resolve this issue, however I chose to utilise the other solution so my library did not form a dependency on the extensions library (for the moment).

the OLD Code:

   1: private class OrSpecification : Specification<T>

   2: {

   3:     private readonly ISpecification<T> left;

   4:     private readonly ISpecification<T> right;

   5:     public OrSpecification(ISpecification<T> left,ISpecification<T> right)

   6:     {

   7:         this.left = left;

   8:         this.right = right;

   9:

  10:         this._evalFunc =

  11:             (Func<T, bool>)Func<T, bool>.Combine

  12:             (left.EvalPredicate.Compile(),

  13:             right.EvalPredicate.Compile());

  14:

  15:         ParameterExpression parameter =

  16:             Expression.Parameter(typeof(T), “p”);

  17:         var invokedExpression =

  18:             Expression.Invoke(left.EvalPredicate,

  19:                 right.EvalPredicate.Parameters.Cast<Expression>());

  20:         _evalPredicate =

  21:             Expression.Lambda<Func<T, bool>>

  22:             (Expression.Or(right.EvalPredicate.Body,

  23:             invokedExpression), right.EvalPredicate.Parameters);

  24:     }

  25:     public override bool Matches(T entity)

  26:     {

  27:         return EvalPredicate.Compile().Invoke(entity);

  28:     }

  29: }

Line 18 is the offending line of code.

My NEW Code:

   1: private class OrSpecification : Specification<T>

   2: {

   3:     private readonly ISpecification<T> left;

   4:     private readonly ISpecification<T> right;

   5:     public OrSpecification(ISpecification<T> left,ISpecification<T> right)

   6:     {

   7:         this.left = left;

   8:         this.right = right;

   9:

  10:         this._evalFunc =

  11:             (Func<T, bool>)Func<T, bool>.Combine

  12:             (left.EvalPredicate.Compile(),

  13:             right.EvalPredicate.Compile());

  14:

  15:         _evalPredicate = left.EvalPredicate.Or(right.EvalPredicate);

  16:     }

  17:     public override bool Matches(T entity)

  18:     {

  19:         return EvalPredicate.Compile().Invoke(entity);

  20:     }

  21: }

In short, the extension methods in Colin’s post will kick in and rewrite the behaviour of the .And and .Or method avoiding the need to call Invoke(). This method of composing or ‘rewriting’ as Colin put’s it, also requires a copy of the ExpressionVisitor class which is internal to the Entity Framework. You can find a copy of the ExpressionVisitor here on the wayward blog.

So now I can use my specifications with the Entity Framework! For example if I wish to query my venerable Northwind database and ask for all the products that are now discontinued that are part of existing orders from customers in either Germany and the USA, I can write the following code:

   1: [Test()]

   2: public void RefineCombinedSpecifications()

   3: {

   4:     Specification<Customer> german_customer_spec =

   5:         new Specification<Customer>(c => c.Country == “Germany”);

   6:

   7:     Specification<Customer> us_customer_spec =

   8:         new Specification<Customer>(c => c.Country == “Usa”);

   9:

  10:     Specification<Product> ords_with_discontinued_prods =

  11:         new Specification<Product>(p => p is DiscontinuedProduct);

  12:

  13:     var comb_country_spec = (german_customer_spec | us_customer_spec);

  14:

  15:     using (var ctx = new NorthwindEntities())

  16:     {

  17:         var discontinued_products_on_order =

  18:             (ObjectQuery<Product>)

  19:             (from p in ctx.Products

  20:             .Where(ords_with_discontinued_prods.EvalPredicate)

  21:             from od in ctx.OrderDetails

  22:             from o in ctx.Orders

  23:             from c in ctx.Customers

  24:             .Where(comb_country_spec.EvalPredicate)

  25:             where od.ProductID == p.ProductID &&

  26:                   o.OrderID == od.OrderID &&

  27:                   c.CustomerID == o.Customer.CustomerID

  28:             select p).Distinct();

  29:

  30:         Console.WriteLine(discontinued_products_on_order.ToTraceString());

  31:

  32:         foreach (var product in discontinued_products_on_order)

  33:         {

  34:             Console.WriteLine(“The product ID is {0} with a name of {1}”,

  35:                 product.ProductID, product.ProductName);

  36:         }

  37:     }

  38:

  39:     Console.ReadLine();

  40: }

What’s the benefit you ask? Well the specification class offers me both equality testing (check out the matches method in the download), dynamic querying and and injection as demonstrated in the Repository pattern as here. Next up I will look at flipping open the Repository pattern so it supports LINQ To SQL and the Entity Framework and when the Repository and the Fetching Strategies have been refactored I will post a completely updated version.

I am pretty sure that too much attention in my resume given to practices such as DDD and DI /IoC amongst other things, has been been perceived as fringe and understanding of their value was getting lost in some cases. Typically employers and recruiters are often more interested in how many years of Ajax, ASP.Net, Web Services, ADO.Net etc that you have and I should point out that this is not a criticism of either merely an observation; it comes down to the individual to demonstrate what indeed the value of such knowledge and skills are to any relevant interested party.

So basically I guess my point is this, if your constantly finding yourself perplexed by  what skill you need next, then perhaps you should look at the outlying aspects rather than the obvious and make sure that you give some time to practices or learning new patterns that will help improve the quality of your work regardless of your technology choices. I should point out that whilst many would consider Inversion of Control a technology (I use IoC as an example here), I consider it more a methodology or design practice for the sake of this post and demonstrating the point I am trying to make.

So rather than worry about WCF or WF 4.0 or some other fancy PDC 2008 technology today, perhaps look at Castle Windsor or Spring.Net and begin to get to grips with how DI / IoC can help you write better software or even buy Jimmy Nilsson or Eric Evans books and have a look at Domain Driven Design and see what you can learn from that approach - a wise man once told me "it’s not always about the latest tech!"

PS: I am not saying you should ignore new things as a matter of course (I plan to look at Oslo and M in the coming months myself) but try to balance and give some priority to assigning value to that of the here and now!

I have found to date that I can continue with using the Repository approach along with the Specification Pattern (for dynamic querying) and Fetching Strategies and that was a big criteria for me. There are of course some lingering frustrations with Version 1.0 however at this point I am satisfied that the Entity Framework team will address those in subsequent releases and for the moment I will endure.

In the meantime I thought it was worth taking the same approach as I had with LINQ To SQL and see what was possible with respect to implementing the Specification Pattern in order to provide dynamic querying ability (minus the repository - for the moment only).

Let’s start with a given Entity Model:

I am not going to use much of this model for the purpose of this post but some time soon I will look at how to implement a Fetching Strategies with Entity Framework in a similar manner as that which I demonstrated with LINQ To SQL, but let’s move forward with the specification patterns for now.

So given my model has Orders which aggregate Order_Details and Orders may contain discontinued products I might hypothetically want to sum the total of my unfulfilled problem orders where they contain discontinued products. If I just whip out my specification library (built for LINQ’ish entity / object matching and LINQ To SQL dynamic querying) and I attempt to use it directly with the Entity Framework in this fashion, I get the same behaviour as I expected previously with the other technologies.

static void Main(string[] args)
{
    Specification<Order> order_spec =
        new Specification<Order>(o => o.Order_Details.All
            (od => od.Product is DiscontinuedProduct));

    using (var ctx = new NorthwindEntities())
    {
        ObjectQuery<Order> orders =
            (ObjectQuery<Order>)
            from o in ctx.Orders
                .Include(“Order_Details”)
                .Include(“Customer”)
            .Where(order_spec.EvalPredicate)
            select o;

        Console.WriteLine(orders.ToTraceString());

        try
        {
            foreach (var order in orders)
            {
                var sumup =
                    order.Order_Details.Sum
                    (od => od.Quantity * od.UnitPrice);
                Console.WriteLine(sumup.ToString());
            }
        }
        catch (ArgumentException argEx)
        {
            Console.WriteLine(argEx.Message);
        }
    }

    Console.ReadLine();
}

Ok, that’s great but now I want to try combining specifications which I can do by taking advantage of the operator overloading for OR and AND. Bam, crash it comes tumbling down.

Now its late and I am starting to get annoyed with the Entity Framework. As it turns out (as far as I can tell), LINQ to SQL is far more pliable in managing dynamic queries. Why? Well EF doesn’t play nice with Expression<T>, specifically Expression<Func<T>> etc. Errors arise when you build and invoke Expressions because the Entity Framework doesn’t support Expression.Invoke which is required to combine Expressions.

private class OrSpecification : Specification<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;

        this._evalFunc =
            (Func<T, bool>)Func<T, bool>.Combine
            (left.EvalPredicate.Compile(),
            right.EvalPredicate.Compile());

        ParameterExpression parameter =
            Expression.Parameter(typeof(T), “p”);
        var invokedExpression =
            Expression.Invoke(left.EvalPredicate,
                right.EvalPredicate.Parameters.Cast<Expression>());
        _evalPredicate =
            Expression.Lambda<Func<T, bool>>
            (Expression.Or(right.EvalPredicate.Body,
            invokedExpression), right.EvalPredicate.Parameters);
    }
    public override bool Matches(T entity)
    {
        return EvalPredicate.Compile().Invoke(entity);
    }
}

private static void CombinedOrSpecExample()
{
    Specification<Order> order_spec =
        new Specification<Order>(o => o.Order_Details.All
            (od => od.Product is DiscontinuedProduct));

    Specification<Order> german_customer_spec =
        new Specification<Order>(c => c.Customer.Country == “Germany”);

    var orSpec = order_spec | german_customer_spec;

    using (var ctx = new NorthwindEntities())
    {
        var orders =
            (ObjectQuery<Order>)
            from o in ctx.Orders
                .Include(“Order_Details”)
                .Include(“Customer”)
            .Where(orSpec.EvalFunc).AsQueryable<Order>()
             select o;

        Console.WriteLine(orders.ToTraceString());

        try
        {
            foreach (var order in orders)
            {
                var sumup =
                    order.Order_Details.Sum
                    (od => od.Quantity * od.UnitPrice);
                Console.WriteLine(“The sum of orders for order ID: {0} is {1}”,
                    order.OrderID.ToString(), sumup.ToString());
            }
        }
        catch (ArgumentException argEx)
        {
            Console.WriteLine(argEx.Message);
        }
    }
}

This code produces a casting error: