Правильний Linq, де застереження

Я пишу неабияку кількість посилань у своєму щоденному житті, але переважно прості заяви. Я помітив, що при використанні пропозицій де є багато способів їх написання, і кожен з них має однакові результати, наскільки я можу сказати. Наприклад;

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

Здається, це рівнозначно принаймні, що стосується результатів:

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

То чи є насправді різниця, крім синтаксису? Якщо так, то який переважний стиль і чому?

Другий був би більш ефективним, оскільки він просто має один предикат для оцінки щодо кожного елемента колекції, де, як і в першому, він застосовує перший предикат до всіх предметів першим, і результат (який звужується в цей момент) використовується для другого присудка тощо. Результати звужуються з кожним проходом, але все ж це включає кілька проходів.

Також ланцюжок (перший метод) буде працювати лише в тому випадку, якщо ви ANDing ваші предикати. Щось подібне x.Age == 10 || x.Fat == trueне буде працювати з вашим першим методом.

EDIT: LINQ до об'єктів не поводиться так, як я очікував. Можливо, вас зацікавить повідомлення в блозі, про який я щойно писав ...

Вони відрізняються з точки зору того, як буде називатися - перший еквівалентний:

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

коли останній еквівалентний:

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

Тепер, яка різниця, що насправді має значення, залежить від того, наскільки Whereвони викликаються. Якщо це постачальник, що базується на SQL, я очікую, що вони в кінцевому підсумку створять один і той же SQL. Якщо він знаходиться в LINQ to Objects, другий матиме менший рівень непрямості (замість чотирьох будуть задіяні два ітератори). Чи важливі ці рівні опосередкованості щодо швидкості - це вже інше питання.

Як правило, я б використовував декілька whereзастережень, якщо їм здається, що вони представляють значно різні умови (наприклад, це стосується однієї частини об'єкта, а інша - повністю окрема частина) та один whereпункт, коли різні умови тісно пов'язані (наприклад, певне значення більше мінімуму і менше максимуму). В основному варто враховувати читабельність перед будь-якою незначною різницею у виконанні.

Перший буде реалізований:

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

На відміну від набагато простішого (і набагато швидшого, мабуть, швидшого):

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

коли я біжу

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

і

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

проти моєї таблиці клієнтів він видає той же запит 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)

тому в перекладі на sql немає різниці, і ви вже бачили в інших відповідях, як вони будуть перетворені на лямбда-вирази

Заглянувши під капот, два твердження перетворяться на різні представлення запитів. Залежно QueryProviderвідCollection , це може бути оптимізовано далеко чи ні.

Коли це виклик зв'язку-об'єкта, множинне, де пункти призводять до ланцюжка IEnumerables, які читаються один з одного. Використання форми з одним застереженням допоможе тут зробити ефективність.

Коли базовий провайдер переводить його в оператор SQL, великі шанси, що обидва варіанти створять один і той же оператор.