[logicalmind]

I find it somewhat ironic that you try to specify that the term LINQ be limited to LINQ to Objects and then proceed to explain how it doesn't matter whether the provider is for objects or SQL. Granted, his examples are all LINQ to Objects, but I see no need to be that specific. The provider could be Objects, SQL, Parallel Objects, etc. But the LINQ is still the same.

[DrJokepu]

Let me clarify what I meant. Linq to SQL is compiled to SQL queries. SQL queries are not list comprehension, not even on server side (apart from trivial cases). I wasn't trying to suggest that the term "Linq" is limited to Linq to Objects, I was trying to say exactly the opposite.

[logicalmind]

I'm not following why you are trying to specify the providers implementation of the list comprehension when it doesn't matter to the LINQ query you write. LINQ is working on lists and provides standard query operators. When you write a LINQ query it's turned into an expression tree. Based on the provider of the original list the query is turned into an actual implementation of your LINQ query. Whether this is ultimately translated to a SQL query, an LDAP query, assembly instructions, etc. is of little concern to the writer of the LINQ query. Of course, there are some instances where you do care if performance is of importance.

I believe that the point of author was that any time you are iterating over a list, you should really think about whether you can replace the iteration with a LINQ query. It really doesn't matter whether the list being iterated is an underlying list of objects, a table in an RDBMS, etc.

[nlawalker]

> When you write a LINQ query it's turned into an expression tree.

I believe that this is not the case if you are using LINQ to Objects unless you stick an explicit cast in there somewhere, but I could be wrong. I think that if you simply use the LINQ extension methods on an in-memory IEnumerable, they are simple method calls and involve no compilation to an expression tree.