Следует ли отключать ленивую загрузку Entity Framework в веб-приложениях?

В веб-приложениях у вас есть много одновременных запросов от разных пользователей, каждый запрос обрабатывается довольно быстро (по крайней мере, так должно быть), поэтому вы хотите уменьшить количество вызовов БД во время каждого запроса, потому что каждый запрос БД происходит через сеть. При отложенной загрузке каждый раз, когда вы используете реляционное свойство, он делает еще один вызов БД, чтобы загрузить эти связанные данные в вашу коллекцию сущностей. Таким образом, во время один http-запрос вы можете сделать много дополнительных запросов к БД таким образом, что с точки зрения производительности действительно повредит вашему приложению. В обычных сценариях, когда вы изначально извлекаете свои данные из БД, вы уже знаете, какие связанные данные вам нужны, поэтому вы можете использовать нетерпеливая загрузка связанных сущностей для загрузки всего, что вам нужно в один запрос к БД для обработки конкретного http-запроса.

У меня был один старый проект. Я был очень удивлен, когда проверял в профиле sql, сколько запросов поступает в базу данных. Это было около 180(!) для домашней страницы! На главной странице всего два списка по 20-30 пунктов в каждом. Итак, вы должны очень хорошо понимать запросы N+1. Вы должны внимательно проверить его при просмотре кода. Для меня ленивая загрузка доставляет массу проблем. Вы никогда не знаете, сколько запросов поступает в базу данных, когда вы используете эту функцию.

Ленивая загрузка создаст проблему N+1.

Что это означает?

Это означает, что он попадет в БД один раз (как минимум) для каждого загруженного объекта + начальный запрос.

Почему это плохо?

Предположим, у вас есть эти классы Movie и MovieGenre, и у вас есть 100 фильмов с 30 жанрами между ними в БД.

public class Movie
    {
        public int Id { get; set; }

        public string Name { get; set; }

        public virtual MovieGenre MovieGenre { get; set; }

        public byte MovieGenreId { get; set; }
}

public class MovieGenre
    {
        public byte Id { get; set; }

        public string Name { get; set; }
    }

Теперь предположим, что вы переходите на страницу со всеми 100 фильмами (помните 30 жанров кино?), база данных выполнит 31 запрос (30 для каждого жанра фильма + 1 для фильмов), и запросы будут примерно такими:

Исходный запрос (+1 часть):

SELECT Id, Name, MovieGenreId
From Movie

Дополнительные запросы (часть N):

-- 1
SELECT Id, Name
From MovieGenre
Where Id = 1

-- 2
SELECT Id, Name
From MovieGenre
Where Id = 2

-- 3
SELECT Id, Name
From MovieGenre
Where Id = 3

-- 4
SELECT Id, Name
From MovieGenre
Where Id = 4
.
.
.

Стремительная загрузка позволяет избежать всего этого беспорядка и будет использовать один запрос с правильными соединениями.

поскольку вы используете C#, здесь есть инструмент под названием Glipse, который вы можете использовать для дальнейшего понимания проблемы.

Отключение ленивой загрузки предотвратит проблемы с производительностью Select N+1, а также спасение рекурсивной сериализации, однако заменяет их другим артефактом, нулевыми ссылками.

При работе с веб-приложениями я не отключаю ленивую загрузку, а скорее гарантирую, что мои контроллеры/API возвращают сущности нет, а скорее возвращают ViewModels или DTO. Когда вы применяете классы POCO для передачи своим представлениям только того объема данных и структуры, в которых они нуждаются, и используете .Select() или ProjectTo<TViewModel>() Automapper для их заполнения посредством отложенного выполнения, вы избегаете необходимости беспокоиться о ленивой загрузке и повышаете общую производительность. и использование ресурсов для вашего приложения. Технически, используя этот подход, ленивую загрузку можно отключить, поэтому на самом деле это не аргумент за или против ее отключения, а простое действие по отключению ленивой загрузки не сделает ваше веб-приложение «лучше».

Использование ViewModels дает ряд преимуществ:

• Избегает отложенных вызовов загрузки или неожиданных ссылок #null.
• Отправляет только данные, необходимые представлению/потребителю, и ничего больше. (Меньше данных по сети и меньше информации для хакеров с представлениями отладки.)
• Создает эффективные индексируемые запросы к серверу базы данных.
• Предоставляет место для вычисляемых столбцов, которые не сбивают с толку EF.
• Помогает уменьшить проблемы с безопасностью (неожиданные модификации объектов) на обратном пути. (Ленивый разработчик не может просто повторно прикрепить модель представления и зафиксировать ее в БД.)

Так что для меня проблема с веб-приложениями не в ленивой загрузке или нет, а просто в том, чтобы не передавать объекты клиенту. Я вижу слишком много «примеров», когда они передают сущности. Я не считаю это здоровой моделью.

Например, при использовании модели представления первый вопрос звучит так: «Какие данные действительно нужны моему представлению?» Итак, учитывая продукт и категорию продукта, если я хочу отправить объект продукта, но мне также нужно имя категории продукта, например, мы столкнемся с неприятной проблемой, если наша категория продукта содержит набор продуктов, и каждый из этих продуктов имеет категория. Когда мы передаем наш продукт сериализатору, он попадет в эту циклическую ссылку и либо выйдет из строя (оставив ссылку или коллекцию #null), либо выдаст исключение. Но, работая с Select N+1, мы перебирали свойства продукта, нажимали ссылку ProductCategory, а затем «SELECT FROM ProductCategory WHERE ProductCategoryID = 3». Затем, когда мы перебираем эту категорию продуктов, мы попадаем в другую ссылку, и это еще один SELECT .... и так далее по цепочке.

Используя модель представления, вы ограничиваете данные, которые хотите получить, только тем, что нужно представлению. Я создаю модель представления продукта, в которой очерчены поля, которые меня интересуют, независимо от того, откуда берутся данные. Если я хочу что-то вроде продукта, его имя и название категории:

public class ProductViewModel
{
    public int ProductId { get; set; }
    public string ProductName { get; set; }
    public string CategoryName { get; set; }
}

затем загрузить его:

var viewModel = context.Products
    .Where(x => x.ProductId == productId) 
    .Select(x => new ProductViewModel
    {
        ProductId = x.ProductId,
        ProductName = x.Name,
        CategoryName = x.Category.Name
    }).Single();

Сделанный. Никаких ленивых загрузок или жадных загрузок не требуется. Это создает один запрос, который возвращает одну запись только с 3 необходимыми столбцами. (Вместо всей записи продукта и его категории продукта)

По мере усложнения требований мы можем ввести иерархию модели представления, но мы можем продолжать сглаживать связанные данные в зависимости от того, что действительно нужно представлению. В некоторых случаях это может означать выбор анонимного типа, а затем преобразование этих результатов в модели представления, где нам нужно использовать функции и т. д., которые EF не может преобразовать в SQL. Этот подход является мощной и быстрой альтернативой загрузке сущностей, но требует внимания с самого начала, чтобы понять, что конечному потребителю (представлению/API) потребуются данные.

Я думаю, вам нужно начать с нескольких вопросов, прежде чем выбрать один и отказаться от другого:

1. Насколько велик мой набор данных и нужны ли мне связанные данные немедленно? (Это опять же зависит от ваших потребностей)
2. Как уже говорили другие люди о выпуске N+1; однако это становится важным в зависимости от размера вашего набора данных.
3. Будет ли прагматичным иметь обратный путь к серверу для получения связанных данных?
4. Тогда нужны данные. Хотите ли вы, чтобы это было в реальном времени или в кэшированной версии?

Мой вклад во все важные вклады других.

Я бы сказал, что ленивая загрузка, безусловно, поможет пользователю не извлекать данные, когда они используются очень редко.

Представьте, что у вас есть сценарий Master => Details в веб-приложении, и к тому времени вы поняли, что пользователи не так сильно интересуются деталями. (Вы можете анализировать и проверять запросы, инициированные пользователями). Не было бы необходимости заранее загружать детали для каждой основной записи.

С другой стороны, если детали являются основной частью взаимодействия, просто выполните активную загрузку и извлеките весь Master => Detail для каждого.

Помимо ленивой/нетерпеливой загрузки, убедитесь в следующем:

Всегда включайте пейджинг на стороне сервера и загружайте ограниченные данные/загружайте данные по запросу пользователя, когда они перемещаются страница за страницей.

Если в основном запросы на чтение, отключите AutoTracking.