Quando si utilizza LINQ, qual è la differenza tra le clausole && e le clausole multiple?

Question

Sono nuovo di LINQ e scoperto ieri che è possibile avere più clausole WHERE come:

var items = from object in objectList 
where object.value1 < 100 
where object.value2 > 10 
select object; 

Oppure si può scrivere:

var items = from object in objectList 
where object.value1 < 100 
    && object.value2 > 10 
select object; 

Qual è la differenza tra i due?

Answer 1

La prima sarà tradotto in:

objectList.Where(o => o.value1 < 100).Where(o=> o.value2 > 10) 

mentre il secondo sarà tradotto in:

objectList.Where(o => o.value1 < 100 && o.value2 > 10) 

Così, nel primo, si avrà una prima sequenza filtrata che viene nuovamente filtrato (la prima sequenza contiene tutti gli oggetti con valore < 100, la seconda contiene tutti gli oggetti con valore> 10 dalla prima sequenza), mentre la seconda esegue gli stessi confronti nella stessa espressione labda. Questo è valido da Linq agli oggetti, per altri fornitori dipende da come l'espressione è tradotta.

Answer 2

Al livello base, si ottengono due operazioni Where anziché una. L'uso di Reflector è il modo migliore per esaminare ciò che viene fuori dall'altra estremità di un'espressione di query.

Sia che vengano ottimizzati per la stessa cosa dipende dal provider LINQ attuale: è necessario prendere l'intero albero e convertirlo in un'altra sintassi. Per LINQ To Objects, non è così.

C# in Depth è buono per darvi una comprensione di questo argomento.

Answer 3

Il primo si traduce in:

objectList.Where(o => o.value1 < 100) 
      .Where(o => o.value2 > 10); 

mentre il secondo si ottiene:

objectList.Where(o => o.value1 < 100 && o.value2 > 10);  

E 'functionnaly la stessa, e mentre la seconda avrebbe risparmiato una chiamata di metodo, la differenza di prestazioni è trascurabile. Usa ciò che è più leggibile per te.

Cioè, se si sta usando linq agli oggetti. Se si sta utilizzando un provider, dipende da come è implementato (se il predicato non viene preso in considerazione nella query risultante, il risultato può essere non ottimale).

Answer 4

Che ne dici di una risposta: con & & non puoi garantire che entrambe le espressioni siano valutate (se la prima condizione è falsa allora la seconda potrebbe non essere valutata). Con le due clausole in cui puoi, allora. Non ho idea se sia vero ma suona bene per me!

Answer 5

A parità di altre condizioni, sceglierei la versione condition1 && condition2, per motivi di leggibilità del codice.

Answer 6

Ho appena il profilo. Nessuna differenza nel codice SQL

Answer 7

La risposta contrassegnata lo rende un po 'impreciso.

Come detto @Philippe, il primo sarà tradotto in:

objectList.Where(o => o.value1 < 100).Where(o=> o.value2 > 10) 

mentre il secondo sarà tradotto in:

objectList.Where(o => o.value1 < 100 && o.value2 > 10) 

MaLinq ha una poca ottimizzazione per le chiamate con catena Where.

Se si controlla Linq's codice sorgente verrà visualizzato il seguente:

class WhereEnumerableIterator<TSource> : Iterator<TSource> 
{ 
    public override IEnumerable<TSource> Where(Func<TSource, bool> predicate) 
    { 
     return new WhereEnumerableIterator<TSource>(source, 
      CombinePredicates(this.predicate, predicate)); 
    } 
} 

Cosa CombinePredicates non c'è sta combinando i due predicati con && tra di loro:

static Func<TSource, bool> CombinePredicates<TSource>(Func<TSource, bool> predicate1, 
    Func<TSource, bool> predicate2) 
{ 
    return x => predicate1(x) && predicate2(x); 
} 

Quindi objectList.Where(X).Where(Y) equivale a objectList.Where(X && Y) fatta eccezione per il tempo di creazione della query (che è comunque estremamente breve) e l'invocazione di due predicati.

linea di fondo è che esso non filtro o iterare la raccolta due volte - ma una volta composito.