Fabrice's weblog

Tools and Source

News

My .NET Toolbox
An error occured. See the script errors signaled by your web browser.
No tools selected yet
.NET tools by SharpToolbox.com

Read sample chapters or buy LINQ in Action now!
Our LINQ book is also available on AMAZON

.NET jobs

Emplois .NET

Tuneo

ASP.NET Hosting transatlantys

Contact

Me

Others

Selected content

Archives

Query syntax vs. Method syntax

In the official LINQ forum, someone asked whether it's better to use query syntax (query expression) or method syntax (dot notation).

My answer is that it's mostly a matter of tastes and it depends on the query.
If I'm writing a query that uses many query operators that aren't supported by the query syntax, then I use the method syntax. Mixing the two syntaxes in one single query can quickly make it hard to read, with all the parentheses.
If I'm writing a query that consists of only one operation, then I use the method syntax as well.
In other cases, the query syntax has advantages, like the ability to use "range" variables. The ones defined in from clauses. If you use the method syntax, then you have to redeclare the variables in each lambda expression passed as a parameter to a query operator.

Let's consider the following example:

from person in persons
where person.Age > 12
orderby person.LastName
select person.LastName;

Here, person is declared once and used in the where, orderby, and select clauses.
If you write the same query using the method syntax, you have to "redeclare" person each time in the lambda expressions:

persons
  .Where(person => person.Age > 12)
  .OrderBy(person => person.LastName)
  .Select(person => person.LastName);

Another advantage of the query syntax is the ability to use let clauses. This is really useful in complex queries or simply to avoid performing the same operation several times in a query, by storing temporary results in a variable.
Here is a sample query expression with a let clause:

from person in persons
let name = person.FirstName+person.LastName
select new { Name = name, Phones = person.Phones.Count() }

To reproduce the same using the method syntax, you have to write the following:

persons
  .Select(person => new { person = person, name = person.FirstName+person.LastName })
  .Select(x => new { Name = x.name, Phones = x.person.Phones.Count() });

Not so easy to read, don't you think? This is what the compiler generates when it encounters the above query expression, by the way.

There are other advantages to each syntax, but the ones listed above are already enough to decide which one to use in most cases.

Cross-posted from http://linqinaction.net

Comments

Mohammad Azam said:

Hi,

Good post!

I have experienced that the query syntax returns the IEnumerable<T> or IQuerable<T> which the method syntax can also return entities.

I guess the question is that can I return single entities T using the query method?

# January 20, 2008 12:01 PM

Fabrice Marguerie said:

Not really. You have to mix both syntaxes to get single results. e.g.:

var firstAdult =

 (from person in persons

  where person.Age >= 18

  select person.Name).FirstOrDefault();

Which isn't really looking nice, in my opinion.

# January 20, 2008 12:16 PM

Koistya `Navin said:

Why not to simplify it?

persons

 .Select(person => new { Name = person.FirstName + person.LastName, Phones = person.Phones.Count() });

# January 20, 2008 1:31 PM

Joe Chung said:

Method syntax is good for when you want to generate LINQ queries dynamically with expression trees and such.  Query syntax is sweet syntactic sugar, especially when you're doing complicated queries with many lets, joins, and nested projections.

# January 20, 2008 6:23 PM

Fabrice Marguerie said:

Koistya, the example I gave is too simple. A let clause can be used to simplify queries, but also to avoid computing the same things multiple times.

See this other example: linqinaction.net/.../use-the-power-of-let-in-your-linq-queries.aspx

How would you write the query using the method syntax in this case?

# January 20, 2008 7:46 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)