В чем разница между IEnumerable<T> и IQueryable<T> в C# и когда что использовать?

Question

program_me92 · 09.05.2026

В чем разница между IEnumerable<T> и IQueryable<T> в C# и когда что использовать?

Привет, коллеги! Я новичок в C# и работаю с Entity Framework. Постоянно путаюсь, когда нужно возвращать IEnumerable, а когда IQueryable. Вот у меня есть метод в репозитории: ```csharp public IEnumerable GetProductsByCategory(int categoryId) { return _context.Products.Where(p => p.CategoryId == categoryId).ToList(); } ``` Но другой разработчик сказал, что лучше использовать IQueryable. Я переписал: ```csharp public IQueryable GetProductsByCategory(int categoryId) { return _context.Products.Where(p => p.CategoryId == categoryId); } ``` Теперь у меня есть сервис, который вызывает этот метод и потом фильтрует: ```csharp var cheapProducts = repo.GetProductsByCategory(1).Where(p => p.Price < 100).ToList(); ``` В первом случае (с IEnumerable) всё работает, но медленно. Во втором (с IQueryable) — быстрее, но я не понимаю почему. Объясните, пожалуйста, в чем принципиальная разница? Когда мне стоит использовать IEnumerable, а когда IQueryable? И что там за магия с "отложенным выполнением" и "декомпозицией запросов"? Примеры кода приветствуются! Заранее спасибо! <<>>

Ключевое отличие: где выполняется фильтрация

Основная разница между IEnumerable<T> и IQueryable<T> заключается в том, где и как выполняется запрос. Давайте разберем на вашем примере.

Случай 1: IEnumerable<T> — фильтрация в памяти

public IEnumerable<Product> GetProductsByCategory(int categoryId)
{
    return _context.Products.Where(p => p.CategoryId == categoryId).ToList();
}

Что здесь происходит:

_context.Products — это DbSet<Product>, который реализует IQueryable<Product>.
Вызов .Where(p => p.CategoryId == categoryId) создает SQL-запрос WHERE CategoryId = @categoryId.
Вызов .ToList() немедленно выполняет этот SQL-запрос к базе данных и загружает ВСЕ продукты категории в память как List<Product>.
Метод возвращает IEnumerable<Product> — просто коллекцию объектов в памяти.

Теперь в сервисе:

var cheapProducts = repo.GetProductsByCategory(1)
                        .Where(p => p.Price < 100)
                        .ToList();

Второй .Where(p => p.Price < 100) выполняется уже в памяти приложения с помощью LINQ to Objects. Вы загрузили все продукты категории (возможно, тысячи), а потом отфильтровали только дешевые. Это неэффективно!

Случай 2: IQueryable<T> — фильтрация в БД

public IQueryable<Product> GetProductsByCategory(int categoryId)
{
    return _context.Products.Where(p => p.CategoryId == categoryId);
}

Здесь:

Метод возвращает IQueryable<Product> — это не данные, а выражение запроса (SQL-шаблон), который еще не выполнен.
В сервисе вы добавляете еще одну фильтрацию:

var cheapProducts = repo.GetProductsByCategory(1)
                        .Where(p => p.Price < 100)
                        .ToList();

Теперь магия: IQueryable "склеивает" оба условия в один SQL-запрос:

SELECT * FROM Products 
WHERE CategoryId = 1 AND Price < 100

База данных выполняет этот единый запрос и возвращает только нужные строки. В памяти оказывается только финальный результат.

Когда что использовать?

IEnumerable<T>	IQueryable<T>
Данные уже в памяти (List, Array, встроенные коллекции)	Работа с БД через Entity Framework, LINQ to SQL, NHibernate
Нужно выполнить дополнительные операции, которые нельзя перевести в SQL (например, сложная логика на C#)	Хотите строить динамические запросы (добавлять фильтры, сортировку по условию)
Результат небольшой (десятки записей)	Результат потенциально большой — нужно фильтровать на стороне сервера
Запрос уже материализован (вызван ToList(), ToArray(), FirstOrDefault())	Запрос еще не выполнен — можно комбинировать с другими IQueryable

Важные нюансы

1. Отложенное выполнение (Deferred Execution): IQueryable не выполняет запрос, пока вы не вызовете терминальный метод (ToList(), First(), Count(), Any() и т.д.). Это позволяет строить сложные запросы поэтапно.

2. Декомпозиция запросов (Query Composition): Каждый вызов .Where(), .OrderBy(), .Select() на IQueryable добавляет новое условие в SQL, а не выполняет его. Финальный SQL собирается только при материализации.

3. Осторожно с "утечкой" IQueryable: Если вы возвращаете IQueryable из публичного метода, любой код сможет добавить к нему фильтры. Это может привести к неожиданным SQL-запросам или даже к проблемам безопасности (например, если пользователь может влиять на фильтры).

4. Пример плохой практики:

// ПЛОХО: загружаем все, потом фильтруем в памяти
public IEnumerable<Order> GetOrders()
{
    return _context.Orders.ToList(); // все строки из таблицы!
}

// ХОРОШО: пусть БД фильтрует
public IQueryable<Order> GetOrders()
{
    return _context.Orders;
}

В итоге: используйте IQueryable для работы с БД, пока не нужно материализовать результат. А IEnumerable — когда данные уже в памяти или когда вы хотите "заморозить" результат запроса.

<<>>

Практический совет: когда IQueryable может навредить

Хотя IQueryable обычно предпочтительнее для работы с БД, есть ситуации, когда лучше вернуть IEnumerable или даже List:

Защита от множественных обращений к БД: Если вы возвращаете IQueryable и вызываете ToList() несколько раз, каждый вызов выполнит отдельный SQL-запрос. Это может быть неэффективно.
Сериализация: При передаче данных через Web API или gRPC IQueryable нельзя сериализовать. Нужно сначала материализовать в List.
Сложная логика на C#: Если после получения данных из БД нужно выполнить операции, которые нельзя выразить в SQL (например, вызов внешнего API, сложные вычисления), лучше сначала загрузить данные, а потом обрабатывать.
Инкапсуляция: Если ваш репозиторий должен гарантировать, что все фильтры уже применены (например, фильтрация по правам доступа), верните IEnumerable или List, чтобы внешний код не мог "добавить" свои условия.

Пример:

// Репозиторий гарантирует, что пользователь видит только свои заказы
public IEnumerable<Order> GetMyOrders(int userId)
{
    return _context.Orders
        .Where(o => o.UserId == userId)
        .ToList(); // зафиксировали результат
}

Здесь мы намеренно материализуем запрос, чтобы внешний код не мог случайно "сломать" фильтрацию по userId.

0 ответов