Combine predicates with PredicateBuilder

The IdeaBlade.Linq.PredicateBuilder provides the core functionality to build dynamic LINQ Where clauses out of multiple predicates. This topic explores predicate combinations and delves further into PredicateBuilder and PredicateDescription capabilities.

Two kinds of predicate

A predicate is a function that returns true or false for an item it evaluates. A query Where clause takes a predicate that filters items to include in the query result.

Predicates come in two forms in DevForce queries.   

• an object of type Expression<Func<T, bool>>. This is referred to as a predicate expression.
• an object that implements the DevForce IdeaBlade.Core.IPredicateDescription interface such as IdeaBlade.Linq.PredicateDescription.

You use the predicate expression form when defining a LINQ query and you know the type of object the predicate will evaluate. You use the IPredicateDescription form when you don't know the type of object to filter at compile time. 

Why do we need the PredicateBuider?

We need PredicateBuilder because combining predicates of either kind is hard in .NET. Let's illustrate with two predicate expressions.

It's easy to use either of these expressions independently; it's not obvious how to combine them.

The PredicateBuilder can combine two predicates into a third predicate; then we pass that third predicate to the query's Where clause:

Here's a more convenient syntax that uses PredicateBuilder's predicate expression extension methods to do the same thing without mentioning PredicateBuilder explicitly:

PredicateBuilder APIs

The PredicateBuilder is a static class with two kinds of static methods:

1. methods that take predicate expression parameters and return a predicate expression - the strongly typed API.
2. methods that take IPredicateDescription parameters and return an IPredicateDescription - the untyped API.

The two APIs mirror each other. We'll describe the strongly typed API involving predicate expressions and assume confidently that you can extrapolate to the IPredicateDescription methods.

“p” = Predicate Expression, Expression<Func<T, bool>>, where 'T' is the type of the evaluated item. 

All combined predicates must have the same item type (e.g., Product).

The True() and False() methods return predicate expression constants that simply help you jump-start your chaining of PredicateBuilder expressions ... as seen in the examples below.

Additional overloads of Or(), And(), and Not() are extension methods that make fluent composition of predicates a little easier:
  p1.Or(p2)
  p1.And(p2)
  p1.Not()

The parallel extension methods for IPredicateDescription are located in DynamicQueryExtensions rather than PredicateBuilder.

PredicateBuilder examples

Here are some examples using the PredicateBuilder predicate expression methods:

Debugging PredicateBuilder methods

Put a breakpoint on any of the "bigP" lines and ask the debugger to show you the result as a string. Here is the Immediate Window output for 

{p => ((p.ProductName.Contains("Sir") || p.ProductName.Contains("Louisiana")) && (p.UnitPrice > Convert(20)))}

Lazy typed PredicateDescriptions

We usually specify the item type when we create a PredicateDescription. That isn't strictly necessary. We can postpone determining the query type until the PredicateDescription is used in a query. For example:

The variables p1, p2, p3 are well-defined but do not have embedded query types. They can be used in any query for which they are appropriate, e.g.,

The customerQuery compiles but throws at runtime because Customer doesn't have a UnitPrice or Discontinued property. The productQuery and internationalQuery will run because these properties are defined for Product and InternationalProduct.

As a general rule it is best to embed the query type in the PredicateDescription when you define it unless you have a compelling reason to do otherwise. Filtering on anonymous types within a complex query is one such compelling reason.

Convert a PredicateDescription to a "predicate expression"

When a dynamic PredicateDescription has an embedded query type information, you can convert it into a strongly typed predicate expression using the ToLambdaExpression() method. Once converted, the expression is ready to use in a strongly-typed query, the kind of query you typically write in an application. The following code illustrates:

This gambit is only possible when you can pass the PredicateDescription into compiled code that knows the target type ... as happened here. Such occasions are rare but they occur and the ToLambdaExpression() method is standing by when the opportunity to convert presents itself.