Wenn Sie LINQ verwenden, was ist der Unterschied zwischen && und mehreren where-Klauseln?

Question

Ich bin neu in LINQ und entdeckte gestern, dass Sie mehrere where-Klauseln wie haben:

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

Oder Sie schreiben:

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

Was ist der Unterschied zwischen den beiden?

Answer 1

Die erste wird in übersetzt werden:

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

, während die zweite wird in übersetzt werden:

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

So in der ersten, werden Sie eine erste gefilterte Folge haben, dass wird erneut gefiltert (die erste Sequenz enthält alle Objekte mit dem Wert < 100, die zweite enthält alle Objekte mit dem Wert> 10 aus der ersten Sequenz), während die zweite Sequenz dieselben Vergleiche im selben Labda-Ausdruck durchführt. Dies gilt für Linq für Objekte, für andere Anbieter hängt es davon ab, wie der Ausdruck übersetzt wird.

Answer 2

Auf der grundlegendsten Ebene erhalten Sie zwei Where-Operationen statt einer. Mit Reflector können Sie am besten untersuchen, was am anderen Ende eines Abfrageausdrucks ausgegeben wird.

Ob sie auf dasselbe optimiert werden, hängt vom LINQ-Provider ab - sie muss den gesamten Baum übernehmen und in eine andere Syntax konvertieren. Bei LINQ To Objects ist dies nicht der Fall.

C# in Depth ist gut, um Ihnen ein Verständnis für dieses Thema zu geben.

Answer 3

Die erste übersetzt:

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

während letztere Sie bekommt:

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

Es ist functionnaly gleich, und während der zweite würde einen Methodenaufruf ersparen, ist der Unterschied in der Leistung Ist vernachlässigbar. Verwenden Sie, was für Sie besser lesbar ist.

Das heißt, wenn Sie Linq zu Objekten verwenden. Wenn Sie einen Provider verwenden, hängt dies davon ab, wie er implementiert wird (wenn das Prädikat in der resultierenden Abfrage nicht berücksichtigt wird, kann das Ergebnis suboptimal sein).

Answer 4

Wie wäre es damit für eine Antwort: mit & & können Sie nicht garantieren, dass beide Ausdrücke ausgewertet werden (wenn die erste Bedingung falsch ist, dann wird die zweite möglicherweise nicht ausgewertet). Mit den zwei Where-Klauseln kannst du das. Keine Ahnung, ob es stimmt, aber es klingt gut für mich!

Answer 5

Alle anderen Dinge, die gleich sind, würde ich die condition1 && condition2 Version aus Gründen der Lesbarkeit des Codes wählen.

Answer 6

Ich habe nur Profil es. kein Unterschied in SQL-Code

Answer 7

Die markierte Antwort wird es ein wenig ungenau.

Wie @Philippe sagte, wird die erste in übersetzt werden:

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

während der zweite in übersetzt wird:

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

AberLinq a hat wenig Optimierung für verkettete Where Aufrufe.

Wenn Sie Linq's Quellcode prüfen sehen Sie folgendes:

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

Was CombinePredicates tut, ist, um die beiden Prädikate mit && zwischen ihnen kombiniert:

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

So objectList.Where(X).Where(Y) entspricht objectList.Where(X && Y) abgesehen von der Erstellungszeit der Abfrage (die ohnehin extrem kurz ist) und dem Aufruf von zwei Prädikaten.

Unterm Strich ist, dass es nicht Filter oder die Sammlung zwei Mal durchlaufen - aber eine zusammengesetzte Zeit.