Это определенно не тот случай.
LINQ-to-Objects - это набор методов расширения в IEnumerable<T>
, которые позволяют выполнять операции запроса в памяти для произвольных последовательностей объектов. Методы принимают простые делегаты при необходимости.
LINQ-to-Entities - это поставщик LINQ, который имеет набор методов расширения для IQueryable<T>
. Методы создают дерево выражений (именно поэтому делегаты фактически передаются как Expression<>
s), а поставщик создает SQL-запрос на основе своего анализа этого дерева выражений.
В качестве примера рассмотрим следующие запросы:
var query1 = mydb.MyEntity.Select(x => x.SomeProp).Where(x => x == "Prop");
var query2 = mydb.MyEntity.Select(x => x.SomeProp).AsEnumerable().Where(x => x == "Prop");
Первый запрос - это построение дерева выражений, состоящего из выбора и где, с двумя лямбдами, которые на самом деле считаются LambdaExpression
с. Поставщик LINQ-to-Entities преобразует это в SQL, который выбирает и фильтрует.
Второй запрос вставляет AsEnumerable()
, что заставит оставшуюся часть запроса использовать LINQ-to-Objects. В этом случае поставщик будет генерировать SQL на основе только выбора, возвращать все эти записи из базы данных, и тогда фильтрация будет происходить в памяти. Очевидно, что это будет намного медленнее.