É Linq ou Lambda?


105

Eu sei que este é o Linq:

var _Results = from item in _List
                where item.Value == 1
                select item;

E eu sei que isso é Lambda:

var _Results = _List.Where(x => x.Value == 1);

Nota do editor: o acima não é meramente Lambda, é Linq usando a "Sintaxe do método" cujo predicado é um Lambda. Para ficar claro, os dois exemplos acima são Linq (minha postagem original estava incorreta, mas deixei o erro para ilustrar a confusão que levou à pergunta).

Mas o Linq é um subconjunto do Lambda ou o quê?

Por que existem dois técnicos aparentemente idênticos?

Existe uma razão técnica para escolher um em vez do outro?


Respostas:


135

Este é o LINQ (usando sintaxe de consulta):

var _Results = from item in _List
                where item.Value == 1
                select item;

Isso também é LINQ (usando sintaxe de método):

var _Results = _List.Where(x => x.Value == 1);

É interessante notar que esses dois tipos acabam produzindo exatamente o mesmo código. O compilador oferece um serviço ao permitir que você expresse seus desejos da maneira que preferir.

E este é um lambda:

x => x.Value == 1

Quando você opta por usar a sintaxe de método, o LINQ quase sempre é visto em torno de expressões lambda. Mas LINQ e lambdas são duas coisas totalmente diferentes, que podem ser usadas sozinhas.

Atualização: Como svick corretamente aponta, LINQ com sintaxe de consulta também é implementado usando expressões lambda (como mencionado anteriormente, o compilador permite que você escreva em sintaxe de consulta, mas efetivamente a transforma em sintaxe de método nas suas costas). Isso se deve ao fato de que ambos os sabores são totalmente equivalentes e se comportam da mesma maneira (por exemplo, expressões lambda podem causar a criação de fechamentos ).


2
Acho que vale a pena mencionar que a sintaxe de consulta também usa lambdas nos bastidores. Isso pode ser importante por causa dos fechamentos.
svick

34

Ambos são Linq. O segundo está usando Lambdas .

Lambdas são coisas do tipo de método embutido que você está passando como um parâmetro para a função Where no segundo exemplo.

A diferença entre essas duas sintaxes é puramente sintática. O segundo estilo do linq usando chamadas de método é como ele funciona nos bastidores. O primeiro foi criado para ser mais amigável / fácil e o compilador o converte em chamadas de método nos bastidores. Eles devem funcionar da mesma forma para qualquer consulta, embora, é claro, o compilador possa escolher uma interpretação ligeiramente diferente de uma consulta linq complicada do que você faria ao converter para o estilo de método.

Este artigo msdn também pode ser interessante: Sintaxe de consulta LINQ versus sintaxe de método . De relevância particular é: "Em geral, recomendamos a sintaxe de consulta porque geralmente é mais simples e mais legível; no entanto, não há diferença semântica entre a sintaxe do método e a sintaxe da consulta."


6
Pessoalmente, acho a sintaxe do método mais legível - talvez porque a maior parte do meu código seja do tipo "LINQ to Objects". Mas se você tiver muita experiência em SQL, talvez a sintaxe da consulta seja mais fácil de entender no início.
Tom Bushell

@Tom Bushell, até a sintaxe do JOIN? Seriamente?
Jerry Nixon,

@Tom Bushell: eu também. Eu estava parafraseando algo naquela página do MSDN que provavelmente explica por que eles se preocuparam em desenvolver essa sintaxe em vez de ter apenas o estilo do método. Normalmente, estou apenas fazendo coisas relativamente básicas, em vez de junções ou qualquer outra coisa mais complicada (ou seja, principalmente filtragem ou operações de mapeamento um para um).
Chris

@Jerry - como Chris, meu trabalho no LINQ tem sido bastante simples até agora. Eu li que a sintaxe de consulta geralmente é preferível ao fazer SelectMany, Join ou GroupJoin - só não precisei fazer nada parecido - ainda!
Tom Bushell,

1
Internamente, "sintaxe de consulta" era referida nas equipes LINQ to SQL e LINQ to Entities como "sintaxe de compreensão".
DamienG
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.