Linq corretto dove clausole

Scrivo una buona quantità di linq nella mia vita quotidiana, ma soprattutto dichiarazioni semplici. Ho notato che quando si usano clausole where, ci sono molti modi per scriverle e ognuna ha gli stessi risultati per quanto ne so. Per esempio;

from x in Collection
  where x.Age == 10
  where x.Name == "Fido"
  where x.Fat == true
  select x;

Sembra essere equivalente a questo almeno per quanto riguarda i risultati:

from x in Collection
  where x.Age == 10 &&
        x.Name == "Fido" &&
        x.Fat == true
  select x;

Quindi c'è davvero una differenza diversa dalla sintassi? In tal caso, qual è lo stile preferito e perché?

Il secondo sarebbe più efficiente in quanto ha un solo predicato da valutare rispetto a ciascun elemento della raccolta in cui, come nel primo, applica prima il predicato a tutti gli elementi e il risultato (che è ristretto a questo punto) è usato per il secondo predicato e così via. I risultati vengono ridotti ad ogni passaggio, ma comporta comunque più passaggi.

Anche il concatenamento (primo metodo) funzionerà solo se stai ANDando i tuoi predicati. Qualcosa del genere x.Age == 10 || x.Fat == truenon funzionerà con il tuo primo metodo.

EDIT: LINQ to Objects non si comporta come mi aspettavo. Potresti essere interessato al post sul blog che ho appena scritto su questo ...

Sono diversi in termini di ciò che verrà chiamato - il primo equivale a:

Collection.Where(x => x.Age == 10)
          .Where(x => x.Name == "Fido")
          .Where(x => x.Fat == true)

dove quest'ultimo equivale a:

Collection.Where(x => x.Age == 10 && 
                      x.Name == "Fido" &&
                      x.Fat == true)

Ora quale differenza fa effettivamente dipende dall'implementazione di Whereessere chiamato. Se è un provider basato su SQL, mi aspetto che i due finiscano per creare lo stesso SQL. Se è in LINQ to Objects, il secondo avrà meno livelli di indiretta (ci saranno solo due iteratori invece di quattro). Se questi livelli di riferimento indiretto siano significativi in termini di velocità è una questione diversa.

In genere utilizzerei diverse whereclausole se si sentono come se rappresentassero condizioni significativamente diverse (ad esempio, uno ha a che fare con una parte di un oggetto e uno è completamente separato) e una whereclausola quando varie condizioni sono strettamente correlate (ad esempio un valore particolare è maggiore di un minimo e inferiore a un massimo). Fondamentalmente vale la pena considerare la leggibilità prima di ogni leggera differenza di prestazioni.

Il primo sarà implementato:

Collection.Where(x => x.Age == 10)
          .Where(x => x.Name == "Fido") // applied to the result of the previous
          .Where(x => x.Fat == true)    // applied to the result of the previous

Al contrario del molto più semplice (e molto più veloce presumibilmente più veloce):

// all in one fell swoop
Collection.Where(x => x.Age == 10 && x.Name == "Fido" && x.Fat == true)

quando corro

from c in Customers
where c.CustomerID == 1
where c.CustomerID == 2
where c.CustomerID == 3
select c

e

from c in Customers
where c.CustomerID == 1 &&
c.CustomerID == 2 &&
c.CustomerID == 3
select c customer table in linqpad

contro la mia tabella clienti ha generato la stessa query sql

-- Region Parameters
DECLARE @p0 Int = 1
DECLARE @p1 Int = 2
DECLARE @p2 Int = 3
-- EndRegion
SELECT [t0].[CustomerID], [t0].[CustomerName]
FROM [Customers] AS [t0]
WHERE ([t0].[CustomerID] = @p0) AND ([t0].[CustomerID] = @p1) AND ([t0].[CustomerID] = @p2)

quindi nella traduzione in sql non c'è alcuna differenza e hai già visto in altre risposte come verranno convertiti in espressioni lambda

Guardando sotto il cofano, le due affermazioni verranno trasformate in diverse rappresentazioni di query. Dipende daQueryProvider diCollection , questo potrebbe essere ottimizzato o meno.

Quando si tratta di una chiamata linq-to-object, più clausole where porteranno a una catena di IEnumerables che leggono l'una dall'altra. L'uso del modulo a clausola singola aiuterà le prestazioni qui.

Quando il provider sottostante lo traduce in un'istruzione SQL, è probabile che entrambe le varianti creino la stessa istruzione.