concept query expression in category .net

This is an excerpt from Manning's book C# in Depth. Login to get full access to this book.

But if query expressions are no good, why does everyone make such a fuss about them, and about LINQ in general? The first answer is that although query expressions aren’t particularly beneficial for simple tasks, they’re very good for more complicated situations that would be hard to read if written out in the equivalent method calls (and would be fiendish in C# 1 or 2). Let’s make things a little harder by introducing another type—Supplier.

Figure 11.2. Sequence diagram of the execution of a query expression

The query expression is the part in bold. I’ve overridden ToString for each of the entities in the model, so the results of listing 11.1 are as follows:

User: Tim Trotter (Tester)
User: Tara Tutu (Tester)
User: Deborah Denton (Developer)
User: Darren Dahlia (Developer)
User: Mary Malcop (Manager)
User: Colin Carton (Customer)

copy

You may be wondering how useful this is as an example; after all, you could just use SampleData.AllUsers directly in the foreach statement. But we’ll use this query expression—trivial though it is—to introduce two new concepts. First we’ll look at the general nature of the translation process the compiler uses when it encounters a query expression, and then we’ll discuss range variables.

Listing 11.2. The query expression of listing 11.1 translated into a method call

var query = SampleData.AllUsers.Select(user => user); foreach (var user in query) { Console.WriteLine(user); }

copy

The C# 3 compiler translates the query expression into exactly this code before properly compiling it further. In particular, it doesn’t assume that it should use Enumerable .Select, or that List<T> will contain a method called Select. It merely translates the code and then lets the next phase of compilation deal with finding an appropriate method—whether as a straightforward member or as an extension method.^[3] The parameter can be a suitable delegate type or an Expression<T> for an appropriate type T.

This is an excerpt from Manning's book LINQ in Action. Login to get full access to this book.

We will focus on LINQ to Objects, LINQ to SQL, and LINQ to XML in this book, but LINQ is open to new data sources. The three main LINQ providers discussed in this book are built on top of a common LINQ foundation. This foundation consists of a set of building blocks including query operators, query expressions, and expression trees, which allow the LINQ toolset to be extensible.

Until now, in this chapter, we’ve used a syntax based on method calls for our code samples. This is one way to express queries. But most of the time when you look at code based on LINQ, you’ll notice a different syntax: query expressions.

We’ll explain what query expressions are and then describe the relationship between query expressions and query operators.

Here is the same query with a query expression:

from book in SampleData.Books
where book.Title == "Funny Stories"
orderby book.Title
select new {book.Title, book.Price};

copy

The two queries are equivalent. But you might notice that the query formulated with query operators makes extensive use of lambda expressions. Lambda expressions are useful, but too many in a small block of code can be unattractive. Also, in the same query, notice how the book identifier is declared several times. In comparison, in the query expression, you can see that the book identifier only needs to be declared once.

3.4.2. Writing query expressions

Let’s detail what query expressions look like in C# and in VB.NET.

Figure 3.3 shows the exhaustive syntax for a query expression.

Figure 3.3. C# query expression syntax

Let’s review how this syntax is presented in the C# 3.0 language specification. A query expression begins with a from clause and ends with either a select or group clause. The initial from clause can be followed by zero or more from, let, where, join, or orderby clauses.