Chaining Query Operators

In the preceding section, we showed two simple queries, each comprising a single query operator. To build more complex queries, you append additional query operators to the expression, creating a chain. To illustrate, the following query extracts all strings containing the letter “a”, sorts them by length, and then converts the results to uppercase:

using System;
using System.Collections.Generic;
using System.Linq;

class LinqDemo
{
  static void Main()
  {
    string[] names = { "Tom", "Dick", "Harry", "Mary", "Jay" };

    IEnumerable<string> query = names
      .Where   (n => n.Contains ("a"))
      .OrderBy (n => n.Length)
      .Select  (n => n.ToUpper());

    foreach (string name in query) Console.WriteLine (name);
  }
}

JAY
MARY
HARRY

void Test()
{
  foreach (char c in "string1") Console.Write (c);
  foreach (char c in "string2") Console.Write (c);
  foreach (char c in "string3") Console.Write (c);
}

Where, OrderBy, and Select are standard query operators that resolve to extension methods in the Enumerable class (if you import the System.Linq namespace).

We already introduced the Where operator, which emits a filtered version of the input sequence. The OrderBy operator emits a sorted version of its input sequence; the Select method emits a sequence where each input element is transformed or projected with a given lambda expression (n.ToUpper(), in this case). Data flows from left to right through the chain of operators, so the data is first filtered, then sorted, then projected.

Here are the signatures of each of these extension methods (with the OrderBy signature simplified slightly):

public static IEnumerable<TSource> Where<TSource>
  (this IEnumerable<TSource> source, Func<TSource,bool> predicate)

public static IEnumerable<TSource> OrderBy<TSource,TKey>
  (this IEnumerable<TSource> source, Func<TSource,TKey> keySelector)

public static IEnumerable<TResult> Select<TSource,TResult>
  (this IEnumerable<TSource> source, Func<TSource,TResult> selector)

When query operators are chained as in this example, the output sequence of one operator is the input sequence of the next. The complete query resembles a production line of conveyor belts, as illustrated in Figure 8-1.

Figure 8-1. Chaining query operators

We can construct the identical query progressively, as follows:

// You must import the System.Linq namespace for this to compile:

IEnumerable<string> filtered   = names   .Where   (n => n.Contains ("a"));
IEnumerable<string> sorted     = filtered.OrderBy (n => n.Length);
IEnumerable<string> finalQuery = sorted  .Select  (n => n.ToUpper());

finalQuery is compositionally identical to the query we had constructed previously. Further, each intermediate step also comprises a valid query that we can execute:

foreach (string name in filtered)
  Console.Write (name + "|");        // Harry|Mary|Jay|

Console.WriteLine();
foreach (string name in sorted)
  Console.Write (name + "|");        // Jay|Mary|Harry|

Console.WriteLine();
foreach (string name in finalQuery)
  Console.Write (name + "|");        // JAY|MARY|HARRY|

IEnumerable<string> filtered = Enumerable.Where (names,
                                                 n => n.Contains ("a"));
IEnumerable<string> sorted = Enumerable.OrderBy (filtered, n => n.Length);
IEnumerable<string> finalQuery = Enumerable.Select (sorted,
                                                    n => n.ToUpper());

IEnumerable<string> query = names.Where   (n => n.Contains ("a"))
                                 .OrderBy (n => n.Length)
                                 .Select  (n => n.ToUpper());

IEnumerable<string> query =
  Enumerable.Select (
    Enumerable.OrderBy (
      Enumerable.Where (
        names, n => n.Contains ("a")
      ), n => n.Length
    ), n => n.ToUpper()
  );

Composing Lambda Expressions

In previous examples, we fed the following lambda expression to the Where operator:

n => n.Contains ("a")      // Input type=string, return type=bool.

The purpose of the lambda expression depends on the particular query operator. With the Where operator, it indicates whether an element should be included in the output sequence. In the case of the OrderBy operator, the lambda expression maps each element in the input sequence to its sorting key. With the Select operator, the lambda expression determines how each element in the input sequence is transformed before being fed to the output sequence.

The query operator evaluates your lambda expression upon demand—typically once per element in the input sequence. Lambda expressions allow you to feed your own logic into the query operators. This makes the query operators versatile—as well as being simple under the hood. Here’s a complete implementation of Enumerable.Where, exception handling aside:

public static IEnumerable<TSource> Where<TSource>
  (this IEnumerable<TSource> source, Func<TSource,bool> predicate)
{
  foreach (TSource element in source)
    if (predicate (element))
      yield return element;
}

public static IEnumerable<TResult> Select<TSource,TResult>
  (this IEnumerable<TSource> source, Func<TSource,TResult> selector)

string[] names = { "Tom", "Dick", "Harry", "Mary", "Jay" };
IEnumerable<int> query = names.Select (n => n.Length);

foreach (int length in query)
  Console.Write (length + "|");    // 3|4|5|4|3|

public static IEnumerable<TSource> Where<TSource>
  (this IEnumerable<TSource> source, Func<TSource,bool> predicate)

// Slightly simplified:
public static IEnumerable<TSource> OrderBy<TSource,TKey>
  (this IEnumerable<TSource> source, Func<TSource,TKey> keySelector)

string[] names = { "Tom", "Dick", "Harry", "Mary", "Jay" };
IEnumerable<string> sortedByLength, sortedAlphabetically;
sortedByLength       = names.OrderBy (n => n.Length);   // int key
sortedAlphabetically = names.OrderBy (n => n);          // string key

Natural Ordering

The original ordering of elements within an input sequence is significant in LINQ. Some query operators rely on this ordering, such as Take, Skip, and Reverse.

The Take operator outputs the first x elements, discarding the rest:

int[] numbers  = { 10, 9, 8, 7, 6 };
IEnumerable<int> firstThree = numbers.Take (3);     // { 10, 9, 8 }

The Skip operator ignores the first x elements and outputs the rest:

IEnumerable<int> lastTwo    = numbers.Skip (3);     // { 7, 6 }

Reverse does exactly as it says:

IEnumerable<int> reversed   = numbers.Reverse();    // { 6, 7, 8, 9, 10 }

With local queries (LINQ-to-objects), operators such as Where and Select preserve the original ordering of the input sequence (as do all other query operators, except for those that specifically change the ordering).

Other Operators

Not all query operators return a sequence. The element operators extract one element from the input sequence; examples are First, Last, and ElementAt:

int[] numbers    = { 10, 9, 8, 7, 6 };
int firstNumber  = numbers.First();                        // 10
int lastNumber   = numbers.Last();                         // 6
int secondNumber = numbers.ElementAt(1);                   // 9
int secondLowest = numbers.OrderBy(n=>n).Skip(1).First();  // 7

The aggregation operators return a scalar value; usually of numeric type:

int count = numbers.Count();          // 5;
int min = numbers.Min();              // 6;

The quantifiers return a bool value:

bool hasTheNumberNine = numbers.Contains (9);          // true
bool hasMoreThanZeroElements = numbers.Any();          // true
bool hasAnOddElement = numbers.Any (n => n % 2 != 0);  // true

Because these operators return a single element, you don’t usually call further query operators on their result unless that element itself is a collection.

Some query operators accept two input sequences. Examples are Concat, which appends one sequence to another, and Union, which does the same but with duplicates removed:

int[] seq1 = { 1, 2, 3 };
int[] seq2 = { 3, 4, 5 };
IEnumerable<int> concat = seq1.Concat (seq2);    //  { 1, 2, 3, 3, 4, 5 }
IEnumerable<int> union  = seq1.Union (seq2);     //  { 1, 2, 3, 4, 5 }

The joining operators also fall into this category. Chapter 9 covers all the query operators in detail.

Range Variables

The identifier immediately following the from keyword syntax is called the range variable. A range variable refers to the current element in the sequence that the operation is to be performed on.

In our examples, the range variable n appears in every clause in the query. And yet, the variable actually enumerates over a different sequence with each clause:

from    n in names           // n is our range variable
where   n.Contains ("a")     // n = directly from the array
orderby n.Length             // n = subsequent to being filtered
select  n.ToUpper()          // n = subsequent to being sorted

This becomes clear when we examine the compiler’s mechanical translation to fluent syntax:

names.Where   (n => n.Contains ("a"))      // Locally scoped n
     .OrderBy (n => n.Length)              // Locally scoped n
     .Select  (n => n.ToUpper())           // Locally scoped n

As you can see, each instance of n is scoped privately to its own lambda expression.

Query expressions also let you introduce new range variables, via the following clauses:

• let

• into

• An additional from clause

• join

We cover these later in this chapter in the section “Composition Strategies”, and also in Chapter 9, in the sections “Projecting” and “Joining”.

Query Syntax Versus SQL Syntax

Query expressions look superficially like SQL, yet the two are very different. A LINQ query boils down to a C# expression, and so follows standard C# rules. For example, with LINQ, you cannot use a variable before you declare it. In SQL, you can reference a table alias in the SELECT clause before defining it in a FROM clause.

A subquery in LINQ is just another C# expression and so requires no special syntax. Subqueries in SQL are subject to special rules.

With LINQ, data logically flows from left to right through the query. With SQL, the order is less well-structured with regard data flow.

A LINQ query comprises a conveyor belt, or pipeline, of operators that accept and emit sequences whose element order can matter. A SQL query comprises a network of clauses that work mostly with unordered sets.

Query Syntax Versus Fluent Syntax

Query and fluent syntax each have advantages.

Query syntax is simpler for queries that involve any of the following:

• A let clause for introducing a new variable alongside the range variable

• SelectMany, Join, or GroupJoin, followed by an outer range variable reference

(We describe the let clause in the later section, “Composition Strategies”; we describe SelectMany, Join, and GroupJoin in Chapter 9.)

The middle ground is queries that involve the simple use of Where, OrderBy, and Select. Either syntax works well; the choice here is largely personal.

For queries that comprise a single operator, fluent syntax is shorter and less cluttered.

Finally, there are many operators that have no keyword in query syntax. These require that you use fluent syntax—at least in part. This means any operator outside of the following:

Where, Select, SelectMany
OrderBy, ThenBy, OrderByDescending, ThenByDescending
GroupBy, Join, GroupJoin

Mixed-Syntax Queries

If a query operator has no query-syntax support, you can mix query syntax and fluent syntax. The only restriction is that each query-syntax component must be complete (i.e., start with a from clause and end with a select or group clause).

Assuming this array declaration:

string[] names = { "Tom", "Dick", "Harry", "Mary", "Jay" };

the following example counts the number of names containing the letter “a”:

int matches = (from n in names where n.Contains ("a") select n).Count();
// 3

The next query obtains the first name in alphabetical order:

string first = (from n in names orderby n select n).First();   // Dick

The mixed-syntax approach is sometimes beneficial in more complex queries. With these simple examples, however, we could stick to fluent syntax throughout without penalty:

int matches = names.Where (n => n.Contains ("a")).Count();   // 3
string first = names.OrderBy (n => n).First();               // Dick

Where applicable, the remainder of this chapter will show key concepts in both fluent and query syntax.

Reevaluation

Deferred execution has another consequence: a deferred execution query is reevaluated when you re-enumerate:

var numbers = new List<int>() { 1, 2 };

IEnumerable<int> query = numbers.Select (n => n * 10);
foreach (int n in query) Console.Write (n + "|");   // 10|20|

numbers.Clear();
foreach (int n in query) Console.Write (n + "|");   // <nothing>

There are a couple of reasons why reevaluation is sometimes disadvantageous:

• Sometimes you want to “freeze” or cache the results at a certain point in time.

• Some queries are computationally intensive (or rely on querying a remote database), so you don’t want to unnecessarily repeat them.

You can defeat reevaluation by calling a conversion operator, such as ToArray or ToList. ToArray copies the output of a query to an array; ToList copies to a generic List<T>:

var numbers = new List<int>() { 1, 2 };

List<int> timesTen = numbers
  .Select (n => n * 10)

  .ToList();                // Executes immediately into a List<int>

numbers.Clear();
Console.WriteLine (timesTen.Count);      // Still 2

Captured Variables

If your query’s lambda expressions capture outer variables, the query will honor the value of those variables at the time the query runs:

int[] numbers = { 1, 2 };

int factor = 10;
IEnumerable<int> query = numbers.Select (n => n * factor);
factor = 20;
foreach (int n in query) Console.Write (n + "|");   // 20|40|

This can be a trap when building up a query within a for loop. For example, suppose we wanted to remove all vowels from a string. The following, although inefficient, gives the correct result:

IEnumerable<char> query = "Not what you might expect";

query = query.Where (c => c != 'a'),
query = query.Where (c => c != 'e'),
query = query.Where (c => c != 'i'),
query = query.Where (c => c != 'o'),
query = query.Where (c => c != 'u'),

foreach (char c in query) Console.Write (c);  // Nt wht y mght xpct

Now watch what happens when we refactor this with a for loop:

IEnumerable<char> query = "Not what you might expect";
string vowels = "aeiou";

for (int i = 0; i < vowels.Length; i++)
  query = query.Where (c => c != vowels[i]);

foreach (char c in query) Console.Write (c);

An IndexOutOfRangeException is thrown upon enumerating the query, because as we saw in Chapter 4 (see “Capturing Outer Variables”), the compiler scopes the iteration variable in the for loop as if it was declared outside the loop. Hence each closure captures the same variable (i) whose value is 5 when the query is actually enumerated. To solve this, you must assign the loop variable to another variable declared inside the statement block:

for (int i = 0; i < vowels.Length; i++)
{
  char vowel = vowels[i];
  query = query.Where (c => c != vowel);
}

This forces a fresh local variable to be captured on each loop iteration.

foreach (char vowel in vowels)
  query = query.Where (c => c != vowel);

How Deferred Execution Works

Query operators provide deferred execution by returning decorator sequences.

Unlike a traditional collection class, such as an array or linked list, a decorator sequence (in general) has no backing structure of its own to store elements. Instead, it wraps another sequence that you supply at runtime, to which it maintains a permanent dependency. Whenever you request data from a decorator, it in turn must request data from the wrapped input sequence.

Calling Where merely constructs the decorator wrapper sequence, holding a reference to the input sequence, the lambda expression, and any other arguments supplied. The input sequence is enumerated only when the decorator is enumerated.

Figure 8-3 illustrates the composition of the following query:

IEnumerable<int> lessThanTen = new int[] { 5, 12, 3 }.Where (n => n < 10);

Figure 8-3. Decorator sequence

When you enumerate lessThanTen, you’re, in effect, querying the array through the Where decorator.

The good news—if you ever want to write your own query operator—is that implementing a decorator sequence is easy with a C# iterator. Here’s how you can write your own Select method:

public static IEnumerable<TResult> Select<TSource,TResult>
  (this IEnumerable<TSource> source, Func<TSource,TResult> selector)
{
  foreach (TSource element in source)
    yield return selector (element);
}

This method is an iterator by virtue of the yield return statement. Functionally, it’s a shortcut for the following:

public static IEnumerable<TResult> Select<TSource,TResult>
  (this IEnumerable<TSource> source, Func<TSource,TResult> selector)
{
  return new SelectSequence (source, selector);
}

where SelectSequence is a (compiler-written) class whose enumerator encapsulates the logic in the iterator method.

Hence, when you call an operator such as Select or Where, you’re doing nothing more than instantiating an enumerable class that decorates the input sequence.

Chaining Decorators

Chaining query operators creates a layering of decorators. Consider the following query:

IEnumerable<int> query = new int[] { 5, 12, 3 }.Where   (n => n < 10)
                                               .OrderBy (n => n)
                                               .Select  (n => n * 10);

Each query operator instantiates a new decorator that wraps the previous sequence (rather like a Russian nesting doll). The object model of this query is illustrated in Figure 8-4. Note that this object model is fully constructed prior to any enumeration.

When you enumerate query, you’re querying the original array, transformed through a layering or chain of decorators.

Figure 8-4. Layered decorator sequences

Figure 8-5 shows the same object composition in UML syntax. Select’s decorator references the OrderBy decorator, which references Where’s decorator, which references the array. A feature of deferred execution is that you build the identical object model if you compose the query progressively:

IEnumerable<int>
  source    = new int[] { 5, 12, 3 },
  filtered  = source   .Where   (n => n < 10),
  sorted    = filtered .OrderBy (n => n),
  query     = sorted   .Select  (n => n * 10);

Figure 8-5. UML decorator composition

How Queries Are Executed

Here are the results of enumerating the preceding query:

foreach (int n in query) Console.WriteLine (n);

30
50

Behind the scenes, the foreach calls GetEnumerator on Select’s decorator (the last or outermost operator), which kicks everything off. The result is a chain of enumerators that structurally mirrors the chain of decorator sequences. Figure 8-6 illustrates the flow of execution as enumeration proceeds.

Figure 8-6. Execution of a local query

In the first section of this chapter, we depicted a query as a production line of conveyor belts. Extending this analogy, we can say a LINQ query is a lazy production line where the conveyor belts roll elements only upon demand. Constructing a query constructs a production line—with everything in place—but with nothing rolling. Then when the consumer requests an element (enumerates over the query), the rightmost conveyor belt activates; this in turn triggers the others to roll—as and when input sequence elements are needed. LINQ follows a demand-driven pull model, rather than a supply-driven push model. This is important—as we’ll see later—in allowing LINQ to scale to querying SQL databases.

Subqueries and Deferred Execution

An element or aggregation operator such as First or Count in a subquery doesn’t force the outer query into immediate execution—deferred execution still holds for the outer query. This is because subqueries are called indirectly—through a delegate in the case of a local query, or through an expression tree in the case of an interpreted query.

An interesting case arises when you include a subquery within a Select expression. In the case of a local query, you’re actually projecting a sequence of queries—each itself subject to deferred execution. The effect is generally transparent, and it serves to further improve efficiency. We revisit Select subqueries in some detail in Chapter 9.

Progressive Query Building

At the start of the chapter, we demonstrated how you could build a fluent query progressively:

var filtered   = names    .Where   (n => n.Contains ("a"));
var sorted     = filtered .OrderBy (n => n);
var query      = sorted   .Select  (n => n.ToUpper());

Because each of the participating query operators returns a decorator sequence, the resultant query is the same chain or layering of decorators that you would get from a single-expression query. There are a couple of potential benefits, however, to building queries progressively:

• It can make queries easier to write.

• You can add query operators conditionally. For example:

if (includeFilter) query = query.Where (...)

This is more efficient than:

query = query.Where (n => !includeFilter || <expression>)

because it avoids adding an extra query operator if includeFilter is false.

A progressive approach is often useful in query comprehensions. To illustrate, imagine we want to remove all vowels from a list of names and then present in alphabetical order those whose length is still more than two characters. In fluent syntax, we could write this query as a single expression—by projecting before we filter:

IEnumerable<string> query = names
  .Select  (n => n.Replace ("a", "").Replace ("e", "").Replace ("i", "")
                  .Replace ("o", "").Replace ("u", ""))
  .Where   (n => n.Length > 2)
  .OrderBy (n => n);

RESULT: { "Dck", "Hrry", "Mry" }

n => Regex.Replace (n, "[aeiou]", "")

Translating this directly into a query expression is troublesome because the select clause must come after the where and orderby clauses. And if we rearrange the query so as to project last, the result would be different:

IEnumerable<string> query =
  from    n in names
  where   n.Length > 2
  orderby n
  select  n.Replace ("a", "").Replace ("e", "").Replace ("i", "")
           .Replace ("o", "").Replace ("u", "");

RESULT: { "Dck", "Hrry", "Jy", "Mry", "Tm" }

Fortunately, there are a number of ways to get the original result in query syntax. The first is by querying progressively:

IEnumerable<string> query =
  from   n in names
  select n.Replace ("a", "").Replace ("e", "").Replace ("i", "")
          .Replace ("o", "").Replace ("u", "");

query = from n in query where n.Length > 2 orderby n select n;

RESULT: { "Dck", "Hrry", "Mry" }

The into Keyword

The into keyword lets you “continue” a query after a projection and is a shortcut for progressively querying. With into, we can rewrite the preceding query as:

IEnumerable<string> query =
  from   n in names
  select n.Replace ("a", "").Replace ("e", "").Replace ("i", "")
          .Replace ("o", "").Replace ("u", "")
  into noVowel
    where noVowel.Length > 2 orderby noVowel select noVowel;

The only place you can use into is after a select or group clause. into “restarts” a query, allowing you to introduce fresh where, orderby, and select clauses.

The equivalent of into in fluent syntax is simply a longer chain of operators.

var query =
  from n1 in names
  select n1.ToUpper()
  into n2                              // Only n2 is visible from here on.
    where n1.Contains ("x")            // Illegal: n1 is not in scope.
    select n2;

var query = names
  .Select (n1 => n1.ToUpper())
  .Where  (n2 => n1.Contains ("x"));     // Error: n1 no longer in scope

Wrapping Queries

A query built progressively can be formulated into a single statement by wrapping one query around another. In general terms:

var tempQuery = tempQueryExpr
var finalQuery = from ... in tempQuery ...

can be reformulated as:

var finalQuery = from ... in (tempQueryExpr)

Wrapping is semantically identical to progressive query building or using the into keyword (without the intermediate variable). The end result in all cases is a linear chain of query operators. For example, consider the following query:

IEnumerable<string> query =
  from   n in names
  select n.Replace ("a", "").Replace ("e", "").Replace ("i", "")
          .Replace ("o", "").Replace ("u", "");

query = from n in query where n.Length > 2 orderby n select n;

Reformulated in wrapped form, it’s the following:

IEnumerable<string> query =
  from n1 in
  (
    from   n2 in names
    select n2.Replace ("a", "").Replace ("e", "").Replace ("i", "")
             .Replace ("o", "").Replace ("u", "")
  )
  where n1.Length > 2 orderby n1 select n1;

When converted to fluent syntax, the result is the same linear chain of operators as in previous examples:

IEnumerable<string> query = names
  .Select  (n => n.Replace ("a", "").Replace ("e", "").Replace ("i", "")
                  .Replace ("o", "").Replace ("u", ""))
  .Where   (n => n.Length > 2)
  .OrderBy (n => n);

(The compiler does not emit the final .Select (n => n) because it’s redundant.)

Wrapped queries can be confusing because they resemble the subqueries we wrote earlier. Both have the concept of an inner and outer query. When converted to fluent syntax, however, you can see that wrapping is simply a strategy for sequentially chaining operators. The end result bears no resemblance to a subquery, which embeds an inner query within the lambda expression of another.

Returning to a previous analogy: when wrapping, the “inner” query amounts to the preceding conveyor belts. In contrast, a subquery rides above a conveyor belt and is activated upon demand through the conveyor belt’s lambda worker (as illustrated in Figure 8-7).

Object Initializers

So far, all our select clauses have projected scalar element types. With C# object initializers, you can project into more complex types. For example, suppose, as a first step in a query, we want to strip vowels from a list of names while still retaining the original versions alongside, for the benefit of subsequent queries. We can write the following class to assist:

class TempProjectionItem
{
  public string Original;    // Original name
  public string Vowelless;   // Vowel-stripped name
}

and then project into it with object initializers:

string[] names = { "Tom", "Dick", "Harry", "Mary", "Jay" };

IEnumerable<TempProjectionItem> temp =
  from n in names
  select new TempProjectionItem
  {
    Original  = n,
    Vowelless = n.Replace ("a", "").Replace ("e", "").Replace ("i", "")
                 .Replace ("o", "").Replace ("u", "")
  };

The result is of type IEnumerable<TempProjectionItem>, which we can subsequently query:

IEnumerable<string> query = from   item in temp
                            where  item.Vowelless.Length > 2
                            select item.Original;
Dick
Harry
Mary

Anonymous Types

Anonymous types allow you to structure your intermediate results without writing special classes. We can eliminate the TempProjectionItem class in our previous example with anonymous types:

var intermediate = from n in names

  select new
  {
    Original = n,
    Vowelless = n.Replace ("a", "").Replace ("e", "").Replace ("i", "")
                 .Replace ("o", "").Replace ("u", "")
  };

IEnumerable<string> query = from   item in intermediate
                            where  item.Vowelless.Length > 2
                            select item.Original;

This gives the same result as the previous example, but without needing to write a one-off class. The compiler does the job instead, generating a temporary class with fields that match the structure of our projection. This means, however, that the intermediate query has the following type:

IEnumerable <random-compiler-generated-name>

The only way we can declare a variable of this type is with the var keyword. In this case, var is more than just a clutter reduction device; it’s a necessity.

We can write the whole query more succinctly with the into keyword:

var query = from n in names
  select new
  {
     Original = n,
     Vowelless = n.Replace ("a", "").Replace ("e", "").Replace ("i", "")
                  .Replace ("o", "").Replace ("u", "")
  }
  into temp
  where temp.Vowelless.Length > 2
  select temp.Original;

Query expressions provide a shortcut for writing this kind of query: the let keyword.

The let Keyword

The let keyword introduces a new variable alongside the range variable.

With let, we can write a query extracting strings whose length, excluding vowels, exceeds two characters, as follows:

string[] names = { "Tom", "Dick", "Harry", "Mary", "Jay" };

IEnumerable<string> query =
  from n in names
  let vowelless = n.Replace ("a", "").Replace ("e", "").Replace ("i", "")
                   .Replace ("o", "").Replace ("u", "")
  where vowelless.Length > 2
  orderby vowelless
  select n;       // Thanks to let, n is still in scope.

The compiler resolves a let clause by projecting into a temporary anonymous type that contains both the range variable and the new expression variable. In other words, the compiler translates this query into the preceding example.

let accomplishes two things:

• It projects new elements alongside existing elements.

• It allows an expression to be used repeatedly in a query without being rewritten.

The let approach is particularly advantageous in this example because it allows the select clause to project either the original name (n) or its vowel-removed version (vowelless).

You can have any number of let statements, before or after a where statement (see Figure 8-2). A let statement can reference variables introduced in earlier let statements (subject to the boundaries imposed by an into clause). let reprojects all existing variables transparently.

A let expression need not evaluate to a scalar type: sometimes it’s useful to have it evaluate to a subsequence, for instance.

How Interpreted Queries Work

Let’s examine how the preceding query is processed.

First, the compiler converts query syntax to fluent syntax. This is done exactly as with local queries:

IQueryable<string> query = customers.Where   (n => n.Name.Contains ("a"))
                                    .OrderBy (n => n.Name.Length)
                                    .Select  (n => n.Name.ToUpper());

Next, the compiler resolves the query operator methods. Here’s where local and interpreted queries differ—interpreted queries resolve to query operators in the Queryable class instead of the Enumerable class.

To see why, we need to look at the customers variable, the source upon which the whole query builds. customers is of type Table<T>, which implements IQueryable<T> (a subtype of IEnumerable<T>). This means the compiler has a choice in resolving Where: it could call the extension method in Enumerable or the following extension method in Queryable:

public static IQueryable<TSource> Where<TSource> (this
  IQueryable<TSource> source, Expression <Func<TSource,bool>> predicate)

The compiler chooses Queryable.Where because its signature is a more specific match.

Queryable.Where accepts a predicate wrapped in an Expression<TDelegate> type. This instructs the compiler to translate the supplied lambda expression—in other words, n=>n.Name.Contains("a")—to an expression tree rather than a compiled delegate. An expression tree is an object model based on the types in System.Linq.Expressions that can be inspected at runtime (so that LINQ to SQL or EF can later translate it to a SQL statement).

Because Queryable.Where also returns IQueryable<T>, the same process follows with the OrderBy and Select operators. The end result is illustrated in Figure 8-9. In the shaded box, there is an expression tree describing the entire query that can be traversed at runtime.

Figure 8-9. Interpreted query composition

Combining Interpreted and Local Queries

A query can include both interpreted and local operators. A typical pattern is to have the local operators on the outside and the interpreted components on the inside; in other words, the interpreted queries feed the local queries. This pattern works well with LINQ-to-database queries.

For instance, suppose we write a custom extension method to pair up strings in a collection:

public static IEnumerable<string> Pair (this IEnumerable<string> source)
{
  string firstHalf = null;
  foreach (string element in source)
    if (firstHalf == null)
      firstHalf = element;
    else
    {
      yield return firstHalf + ", " + element;
      firstHalf = null;
    }
}

We can use this extension method in a query that mixes LINQ to SQL and local operators:

DataContext dataContext = new DataContext ("connection string");
Table<Customer> customers = dataContext.GetTable <Customer>();

IEnumerable<string> q = customers
  .Select (c => c.Name.ToUpper())
  .OrderBy (n => n)
  .Pair()                         // Local from this point on.
  .Select ((n, i) => "Pair " + i.ToString() + " = " + n);

foreach (string element in q) Console.WriteLine (element);

Pair 0 = HARRY, MARY
Pair 1 = TOM, DICK

Because customers is of a type implementing IQueryable<T>, the Select operator resolves to Queryable.Select. This returns an output sequence also of type IQueryable<T>, so the OrderBy operator similarly resolves to Queryable.OrderBy. But the next query operator, Pair, has no overload accepting IQueryable<T>—only the less specific IEnumerable<T>. So, it resolves to our local Pair method—wrapping the interpreted query in a local query. Pair also returns IEnumerable, so the Select that follows resolves to another local operator.

On the LINQ to SQL side, the resulting SQL statement is equivalent to:

SELECT UPPER (Name) FROM Customer ORDER BY UPPER (Name)

The remaining work is done locally. In effect, we end up with a local query (on the outside), whose source is an interpreted query (the inside).

AsEnumerable

Enumerable.AsEnumerable is the simplest of all query operators. Here’s its complete definition:

public static IEnumerable<TSource> AsEnumerable<TSource>
              (this IEnumerable<TSource> source)
{
    return source;
}

Its purpose is to cast an IQueryable<T> sequence to IEnumerable<T>, forcing subsequent query operators to bind to Enumerable operators instead of Queryable operators. This causes the remainder of the query to execute locally.

To illustrate, suppose we had a MedicalArticles table in SQL Server and wanted to use LINQ to SQL or EF to retrieve all articles on influenza whose abstract contained less than 100 words. For the latter predicate, we need a regular expression:

Regex wordCounter = new Regex (@"(w|[-'])+");

var query = dataContext.MedicalArticles
  .Where (article => article.Topic == "influenza" &&
                     wordCounter.Matches (article.Abstract).Count < 100);

The problem is that SQL Server doesn’t support regular expressions, so the LINQ-to-db providers will throw an exception, complaining that the query cannot be translated to SQL. We can solve this by querying in two steps: first retrieving all articles on influenza through a LINQ to SQL query, and then filtering locally for abstracts of less than 100 words:

Regex wordCounter = new Regex (@"(w|[-'])+");

IEnumerable<MedicalArticle> sqlQuery = dataContext.MedicalArticles
  .Where (article => article.Topic == "influenza");

IEnumerable<MedicalArticle> localQuery = sqlQuery
  .Where (article => wordCounter.Matches (article.Abstract).Count < 100);

Because sqlQuery is of type IEnumerable<MedicalArticle>, the second query binds to the local query operators, forcing that part of the filtering to run on the client.

With AsEnumerable, we can do the same in a single query:

Regex wordCounter = new Regex (@"(w|[-'])+");

var query = dataContext.MedicalArticles
  .Where (article => article.Topic == "influenza")

  .AsEnumerable()
  .Where (article => wordCounter.Matches (article.Abstract).Count < 100);

An alternative to calling AsEnumerable is to call ToArray or ToList. The advantage of AsEnumerable is that it doesn’t force immediate query execution, nor does it create any storage structure.

We demonstrate combined interpreted and local queries further in Chapter 10.

LINQ to SQL Entity Classes

L2S allows you to use any class to represent data, as long as you decorate it with appropriate attributes. Here’s a simple example:

[Table]
public class Customer
{
  [Column(IsPrimaryKey=true)]
  public int ID;

  [Column]
  public string Name;
}

The [Table] attribute, in the System.Data.Linq.Mapping namespace, tells L2S that an object of this type represents a row in a database table. By default, it assumes the table name matches the class name; if this is not the case, you can specify the table name as follows:

[Table (Name="Customers")]

A class decorated with the [Table] attribute is called an entity in L2S. To be useful, its structure must closely—or exactly—match that of a database table, making it a low-level construct.

The [Column] attribute flags a field or property that maps to a column in a table. If the column name differs from the field or property name, you can specify the column name as follows:

[Column (Name="FullName")]
public string Name;

The IsPrimaryKey property in the [Column] attribute indicates that the column partakes in the table’s primary key and is required for maintaining object identity, as well as allowing updates to be written back to the database.

Instead of defining public fields, you can define public properties in conjunction with private fields. This allows you to write validation logic into the property accessors. If you take this route, you can optionally instruct L2S to bypass your property accessors and write to the field directly when populating from the database:

string _name;

[Column (Storage="_name")]
public string Name { get { return _name; } set { _name = value; } }

Column(Storage="_name") tells L2S to write directly to the _name field (rather than the Name property) when populating the entity. L2S’s use of reflection allows the field to be private—as in this example.

Entity Framework Entity Classes

As with L2S, EF lets you use any class to represent data (although you have to implement special interfaces if you want functionality such as navigation properties).

The following entity class, for instance, represents a customer that ultimately maps to a customer table in the database:

// You'll need to reference System.Data.Entity.dll

[EdmEntityType (NamespaceName = "NutshellModel", Name = "Customer")]
public partial class Customer
{
  [EdmScalarPropertyAttribute (EntityKeyProperty=true, IsNullable=false)]
  public int ID { get; set; }

  [EdmScalarProperty (EntityKeyProperty = false, IsNullable = false)]
  public string Name { get; set; }
}

Unlike with L2S, however, a class such as this is not enough on its own. Remember that with EF, you’re not querying the database directly—you’re querying a higher-level model called the Entity Data Model (EDM). There needs to be some way to describe the EDM, and this is most commonly done via an XML file with an .edmx extension, which contains three parts:

• The conceptual model, which describes the EDM in isolation of the database

• The store model, which describes the database schema

• The mapping, which describes how the conceptual model maps to the store

The easiest way to create an .edmx file is to add an “ADO.NET Entity Data Model” project item in Visual Studio and then follow the wizard for generating entities from a database. This creates not only the .edmx file, but the entity classes as well.

The designer assumes that you initially want a simple 1:1 mapping between tables and entities. You can enrich this, however, by tweaking the EDM either with the designer or by editing the underlying .edmx file that it creates for you. Here are some of the things you can do:

• Map several tables into one entity.

• Map one table into several entities.

• Map inherited types to tables using the three standard kinds of strategies popular in the ORM world.

The three kinds of inheritance strategies are:

Table per hierarchy

A single table maps to a whole class hierarchy. The table contains a discriminator column to indicate which type each row should map to.

Table per type

A single table maps to one type, meaning that an inherited type maps to several tables. EF generates a SQL JOIN when you query an entity, to merge all its base types together.

Table per concrete type

A separate table maps to each concrete type. This means that a base type maps to several tables and EF generates a SQL UNION when you query for entities of a base type.

(In contrast, L2S supports only table per hierarchy.)

EF also lets you query through the EDM without LINQ—using a textual language called Entity SQL (ESQL). This can be useful for dynamically constructed queries.

DataContext and ObjectContext

Once you’ve defined entity classes (and an EDM in the case of EF), you can start querying. The first step is to instantiate a DataContext (L2S) or ObjectContext (EF), specifying a connection string:

var l2sContext = new DataContext ("database connection string");
var efContext = new ObjectContext ("entity connection string");

With L2S, you pass in the database connection string; with EF, you must pass an entity connection string, which incorporates the database connection string plus information on how to find the EDM. (If you’ve created an EDM in Visual Studio, you can find the entity connection string for your EDM in the app.config file.)

You can then obtain a queryable object by calling GetTable (L2S) or CreateObjectSet (EF). The following example uses the Customer class that we defined earlier:

var context = new DataContext ("database connection string");
Table<Customer> customers = context.GetTable <Customer>();

Console.WriteLine (customers.Count());              // # of rows in table.

Customer cust = customers.Single (c => c.ID == 2);  // Retrieves Customer
                                                    // with ID of 2.

Here’s the same thing with EF:

var context = new ObjectContext ("entity connection string");
context.DefaultContainerName = "NutshellEntities";
ObjectSet<Customer> customers = context.CreateObjectSet<Customer>();

Console.WriteLine (customers.Count());              // # of rows in table.

Customer cust = customers.Single (c => c.ID == 2);  // Retrieves Customer
                                                    // with ID of 2.

A DataContext/ObjectContext object does two things. First, it acts as a factory for generating objects that you can query. Second, it keeps track of any changes that you make to your entities so that you can write them back. We can continue our previous example to update a customer with L2S as follows:

Customer cust = customers.OrderBy (c => c.Name).First();
cust.Name = "Updated Name";
context.SubmitChanges();

With EF, the only difference is that you call SaveChanges instead:

Customer cust = customers.OrderBy (c => c.Name).First();
cust.Name = "Updated Name";
context.SaveChanges();

class NutshellContext : DataContext    // For LINQ to SQL
{
  public Table<Customer> Customers => GetTable<Customer>();
  // ... and so on, for each table in the database
}

class NutshellContext : ObjectContext   // For Entity Framework
{
  public ObjectSet<Customer> Customers => CreateObjectSet<Customer>();
  // ... and so on, for each entity in the conceptual model
}

var context = new NutshellContext ("connection string");
Console.WriteLine (context.Customers.Count());

context.Customers.MergeOption = MergeOption.NoTracking;

var context = new NutshellContext ("connection string");

Customer a = context.Customers.OrderBy (c => c.Name).First();
Customer b = context.Customers.OrderBy (c => c.ID).First();

customers.Select (c => c.Name);
customers.Select (c => new { Name = c.Name } );
customers.Select (c => new MyCustomType { Name = c.Name } );

customers.Select (c => new Customer { Name = c.Name } );

Associations

The entity generation tools perform another useful job. For each relationship defined in your database, they generate properties on each side that allow you to query that relationship. For example, suppose we define customer and purchase tables in a one-to-many relationship:

create table Customer
(
  ID int not null primary key,
  Name varchar(30) not null
)

create table Purchase
(
  ID int not null primary key,
  CustomerID int references Customer (ID),
  Description varchar(30) not null,
  Price decimal not null
)

With automatically generated entity classes, we can write queries such as this:

var context = new NutshellContext ("connection string");

// Retrieve all purchases made by the first customer (alphabetically):

Customer cust1 = context.Customers.OrderBy (c => c.Name).First();
foreach (Purchase p in cust1.Purchases)
  Console.WriteLine (p.Price);

// Retrieve the customer who made the lowest value purchase:

Purchase cheapest = context.Purchases.OrderBy (p => p.Price).First();
Customer cust2 = cheapest.Customer;

Further, if cust1 and cust2 happened to refer to the same customer, c1 and c2 would refer to the same object: cust1==cust2 would return true.

Let’s examine the signature of the automatically generated Purchases property on the Customer entity. With L2S:

[Association (Storage="_Purchases", OtherKey="CustomerID")]
public EntitySet <Purchase> Purchases { get {...} set {...} }

With EF:

[EdmRelationshipNavigationProperty ("NutshellModel", "FK...", "Purchase")]
public EntityCollection<Purchase> Purchases { get {...} set {...} }

An EntitySet or EntityCollection is like a predefined query, with a built-in Where clause that extracts related entities. The [Association] attribute gives L2S the information it needs to formulate the SQL query; the [EdmRelationshipNavigationProperty] attribute tells EF where to look in the EDM for information about that relationship.

As with any other type of query, you get deferred execution. With L2S, an EntitySet is populated when you enumerate over it; with EF, an EntityCollection is populated when you explicitly call its Load method.

Here’s the Purchases.Customer property, on the other side of the relationship, with L2S:

[Association (Storage="_Customer",ThisKey="CustomerID",IsForeignKey=true)]
public Customer Customer { get {...} set {...} }

Although the property is of type Customer, its underlying field (_Customer) is of type EntityRef. The EntityRef type implements deferred loading, so the related Customer is not retrieved from the database until you actually ask for it.

EF works in the same way, except that it doesn’t populate the property simply by you accessing it: you must call Load on its EntityReference object. This means EF contexts must expose properties for both the actual parent object and its EntityReference wrapper:

[EdmRelationshipNavigationProperty ("NutshellModel", "FK..., "Customer")]
public Customer Customer { get {...} set {...} }

public EntityReference<Customer> CustomerReference { get; set; }

context.ContextOptions.DeferredLoadingEnabled = true;

Deferred Execution with L2S and EF

L2S and EF queries are subject to deferred execution, just like local queries. This allows you to build queries progressively. There is one aspect, however, in which L2S/EF have special deferred execution semantics, and that is when a subquery appears inside a Select expression:

• With local queries, you get double deferred execution, because from a functional perspective, you’re selecting a sequence of queries. So, if you enumerate the outer result sequence, but never enumerate the inner sequences, the subquery will never execute.

• With L2S/EF, the subquery is executed at the same time as the main outer query. This avoids excessive round-tripping.

For example, the following query executes in a single round trip upon reaching the first foreach statement:

var context = new NutshellContext ("connection string");

var query = from c in context.Customers
            select
               from p in c.Purchases
               select new { c.Name, p.Price };

foreach (var customerPurchaseResults in query)
  foreach (var namePrice in customerPurchaseResults)
    Console.WriteLine (namePrice.Name + " spent " + namePrice.Price);

Any EntitySets/EntityCollections that you explicitly project are fully populated in a single round trip:

var query = from c in context.Customers
            select new { c.Name, c.Purchases };

foreach (var row in query)
  foreach (Purchase p in row.Purchases)   // No extra round-tripping
    Console.WriteLine (row.Name + " spent " + p.Price);

But if we enumerate EntitySet/EntityCollection properties without first having projected, deferred execution rules apply. In the following example, L2S and EF execute another Purchases query on each loop iteration:

context.ContextOptions.DeferredLoadingEnabled = true;  // For EF only.

foreach (Customer c in context.Customers)
  foreach (Purchase p in c.Purchases)    // Another SQL round-trip
    Console.WriteLine (c.Name + " spent " + p.Price);

This model is advantageous when you want to selectively execute the inner loop, based on a test that can be performed only on the client:

foreach (Customer c in context.Customers)
  if (myWebService.HasBadCreditHistory (c.ID))
    foreach (Purchase p in c.Purchases)   // Another SQL round trip
      Console.WriteLine (...);

(In Chapter 9, we explore Select subqueries in more detail, in “Projecting”.)

We’ve seen that you can avoid round-tripping by explicitly projecting associations. L2S and EF offer other mechanisms for this, too, which we cover in the following two sections.

Eager Loading in Entity Framework

You can request in EF that associations be eagerly loaded with the Include method. The following enumerates over each customer’s purchases—while generating just one SQL query:

foreach (Customer c in context.Customers.Include ("Purchases"))
  foreach (Purchase p in c.Purchases)
    Console.WriteLine (p.Description);

Include can be used with arbitrary breadth and depth. For example, if each Purchase also had PurchaseDetails and SalesPersons navigation properties, the entire nested structure could be eagerly loaded as follows:

context.Customers.Include ("Purchases.PurchaseDetails")
                 .Include ("Purchases.SalesPersons")

Updates

L2S and EF also keep track of changes that you make to your entities and allow you to write them back to the database by calling SubmitChanges on the DataContext object, or SaveChanges on the ObjectContext object.

L2S’s Table<T> class provides InsertOnSubmit and DeleteOnSubmit methods for inserting and deleting rows in a table; EF’s ObjectSet<T> class provides AddObject and DeleteObject methods to do the same thing. Here’s how to insert a row:

var context = new NutshellContext ("connection string");

Customer cust = new Customer { ID=1000, Name="Bloggs" };
context.Customers.InsertOnSubmit (cust);   // AddObject with EF
context.SubmitChanges();                   // SaveChanges with EF

We can later retrieve that row, update it, and then delete it:

var context = new NutshellContext ("connection string");

Customer cust = context.Customers.Single (c => c.ID == 1000);
cust.Name = "Bloggs2";
context.SubmitChanges();                  // Updates the customer

context.Customers.DeleteOnSubmit (cust);  // DeleteObject with EF
context.SubmitChanges();                  // Deletes the customer

SubmitChanges/SaveChanges gathers all the changes that were made to its entities since the context’s creation (or the last save) and then executes a SQL statement to write them to the database. Any TransactionScope is honored; if none is present, it wraps all statements in a new transaction.

You can also add new or existing rows to an EntitySet/EntityCollection by calling Add. L2S and EF automatically populate the foreign keys when you do this (after calling SubmitChanges or SaveChanges):

Purchase p1 = new Purchase { ID=100, Description="Bike",  Price=500 };
Purchase p2 = new Purchase { ID=101, Description="Tools", Price=100 };

Customer cust = context.Customers.Single (c => c.ID == 1);

cust.Purchases.Add (p1);
cust.Purchases.Add (p2);

context.SubmitChanges();  //  (or SaveChanges with EF)

In this example, L2S/EF automatically writes 1 into the CustomerID column of each of the new purchases (L2S knows to do this because of the association attribute that we defined on the Purchases property; EF knows to do this because of information in the EDM):

[Association (Storage="_Purchases", OtherKey="CustomerID")]
public EntitySet <Purchase> Purchases { get {...} set {...} }

If the Customer and Purchase entities were generated by the Visual Studio designer or the SqlMetal command-line tool, the generated classes would include further code to keep the two sides of each relationship in sync. In other words, assigning the Purchase.Customer property would automatically add the new customer to the Customer.Purchases entity set—and vice versa. We can illustrate this by rewriting the preceding example as follows:

var context = new NutshellContext ("connection string");

Customer cust = context.Customers.Single (c => c.ID == 1);
new Purchase { ID=100, Description="Bike",  Price=500, Customer=cust };
new Purchase { ID=101, Description="Tools", Price=100, Customer=cust };

context.SubmitChanges();   // (SaveChanges with EF)

When you remove a row from an EntitySet/EntityCollection, its foreign key field is automatically set to null. The following disassociates our two recently added purchases from their customer:

var context = new NutshellContext ("connection string");

Customer cust = context.Customers.Single (c => c.ID == 1);

cust.Purchases.Remove (cust.Purchases.Single (p => p.ID == 100));
cust.Purchases.Remove (cust.Purchases.Single (p => p.ID == 101));

context.SubmitChanges();    // Submit SQL to database (SaveChanges in EF)

Because this tries to set each purchase’s CustomerID field to null, Purchase.CustomerID must be nullable in the database; otherwise, an exception is thrown. (Further, the CustomerID field or property in the entity class must be a nullable type.)

To delete child entities entirely, remove them from the Table<T> or ObjectSet<T> instead (this means you much retrieve them first). With L2S:

var c = context;
c.Purchases.DeleteOnSubmit (c.Purchases.Single (p => p.ID == 100));
c.Purchases.DeleteOnSubmit (c.Purchases.Single (p => p.ID == 101));
c.SubmitChanges();         // Submit SQL to database

With EF:

var c = context;
c.Purchases.DeleteObject (c.Purchases.Single (p => p.ID == 100));
c.Purchases.DeleteObject (c.Purchases.Single (p => p.ID == 101));
c.SaveChanges();         // Submit SQL to database

API Differences Between L2S and EF

As we’ve seen, L2S and EF are similar in the aspect of querying with LINQ and performing updates. Table 8-1 summarizes the API differences.

Expression Trees

We said previously that an implicit conversion from a lambda expression to Expression<TDelegate> causes the C# compiler to emit code that builds an expression tree. With some programming effort, you can do the same thing manually at runtime—in other words, dynamically build an expression tree from scratch. The result can be cast to an Expression<TDelegate> and used in LINQ-to-db queries or compiled into an ordinary delegate by calling Compile.

The Expression DOM

An expression tree is a miniature code DOM. Each node in the tree is represented by a type in the System.Linq.Expressions namespace; these types are illustrated in Figure 8-10.

Note

From Framework 4.0, this namespace features additional expression types and methods to support language constructs that can appear in code blocks. These are for the benefit of the DLR and not lambda expressions. In other words, code-block-style lambdas still cannot be converted to expression trees:

Expression<Func<Customer,bool>> invalid =
  c => { return true; }  // Code blocks not permitted

The base class for all nodes is the (nongeneric) Expression class. The generic Expression<TDelegate> class actually means “typed lambda expression” and might have been named LambdaExpression<TDelegate> if it wasn’t for the clumsiness of this:

LambdaExpression<Func<Customer,bool>> f = ...

Expression<T>’s base type is the (nongeneric) LambdaExpression class. LamdbaExpression provides type unification for lambda expression trees: any typed Expression<T> can be cast to a LambdaExpression.

The thing that distinguishes LambdaExpressions from ordinary Expressions is that lambda expressions have parameters.

Figure 8-10. Expression types

To create an expression tree, don’t instantiate node types directly; rather, call static methods provided on the Expression class. Here are all the methods:

Add AddChecked And AndAlso ArrayIndex ArrayLength Bind Call Coalesce Condition Constant Convert ConvertChecked Divide

ElementInit Equal ExclusiveOr Field GreaterThan GreaterThanOrEqual Invoke Lambda LeftShift LessThan LessThanOrEqual ListBind ListInit MakeBinary

MakeMemberAccess MakeUnary MemberBind MemberInit Modulo Multiply MultiplyChecked Negate NegateChecked New NewArrayBounds NewArrayInit Not NotEqual

Or OrElse Parameter Power Property PropertyOrField Quote RightShift Subtract SubtractChecked TypeAs TypeIs UnaryPlus

Figure 8-11 shows the expression tree that the following assignment creates:

Expression<Func<string, bool>> f = s => s.Length < 5;

Figure 8-11. Expression tree

We can demonstrate this as follows:

Console.WriteLine (f.Body.NodeType);                     // LessThan
Console.WriteLine (((BinaryExpression) f.Body).Right);   // 5

Let’s now build this expression from scratch. The principle is that you start from the bottom of the tree and work your way up. The bottommost thing in our tree is a ParameterExpression, the lambda expression parameter called “s” of type string:

ParameterExpression p = Expression.Parameter (typeof (string), "s");

The next step is to build the MemberExpression and ConstantExpression. In the former case, we need to access the Length property of our parameter, “s”:

MemberExpression stringLength = Expression.Property (p, "Length");
ConstantExpression five = Expression.Constant (5);

Next is the LessThan comparison:

BinaryExpression comparison = Expression.LessThan (stringLength, five);

The final step is to construct the lambda expression, which links an expression Body to a collection of parameters:

Expression<Func<string, bool>> lambda
  = Expression.Lambda<Func<string, bool>> (comparison, p);

A convenient way to test our lambda is by compiling it to a delegate:

Func<string, bool> runnable = lambda.Compile();

Console.WriteLine (runnable ("kangaroo"));           // False
Console.WriteLine (runnable ("dog"));                // True

Note

The easiest way to figure out which expression type to use is to examine an existing lambda expression in the Visual Studio debugger.

We continue this discussion online, at http://www.albahari.com/expressions/.