Как в Entity Framework Core эффективно загрузить сущность со множеством связанных данных?

А, Entity Framework Core, ну это же классика, блядь! Три способа вытащить связанные данные — как три пути в дремучем лесу, и каждый ведёт в свою задницу, если не разобраться.

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

1. Жадная загрузка (Eager Loading)

Это когда ты такой: «А дай-ка я всё и сразу, нахуй!» Берёшь основную сущность и прицепляешь к ней всё, что висит, одним здоровенным запросом. Используется, когда связанные данные нужны прямо сейчас, а не потом.

var blog = context.Blogs
    .Include(b => b.Posts) // Тащим заодно все посты
        .ThenInclude(p => p.Tags) // А в каждом посте ещё и теги, ёпта
    .Include(b => b.Author) // И автора не забудь, а то кто писал?
    .FirstOrDefault(b => b.Id == blogId);

Что хорошего: Один запрос к базе, и ты знаешь, что получил всё. Предсказуемо, как удар кирпичом по голове. Что плохого: Может так нагрузить запрос, что он превратится в монстра с кучей JOIN, и ты вытащишь овердохуища данных, которые тебе нахуй не сдались. Это как купить весь магазин, чтобы съесть одну шоколадку.

2. Явная загрузка (Explicit Loading)

Тут ты уже умнее. Сначала берёшь главную сущность, а потом, если вдруг понадобилось, идешь в базу за каждым связанным куском отдельно. Полный контроль, как у сапёра с миноискателем.

var blog = context.Blogs.Find(blogId);
// Подумал, и решил: а надо бы посты посмотреть.
context.Entry(blog)
    .Collection(b => b.Posts)
    .Load();
// А, и автора тоже заценить не помешает.
context.Entry(blog)
    .Reference(b => b.Author)
    .Load();

Что хорошего: Сам решаешь, что и когда грузить. Ничего лишнего. Что плохого: Если начнёшь так делать в цикле, получишь знаменитую проблему SELECT N+1, где на каждую запись лезет отдельный запрос. База тебя возненавидит, а приложение будет тормозить как пьяный ёжик.

3. Ленивая загрузка (Lazy Loading)

Вот это магия, блядь! Ты просто обращаешься к свойству, а данные сами подгружаются из базы, как по волшебству. Но волшебство это, конечно, требует жертв.

// Сначала надо настроить контекст, чтобы он такое умел
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.UseLazyLoadingProxies(); // Включаем тёмную сторону силы
}

// В модели свойства должны быть виртуальными
public class Blog
{
    public virtual ICollection<Post> Posts { get; set; } // Виртуальное — ключевое слово!
}

// Использование
var blog = context.Blogs.Find(blogId);
var posts = blog.Posts; // И вот тут, сука, невидимый запрос улетает в базу!

Что хорошего: Удобно, не паришься. Написал код и пошёл пить чай. Что плохого: Скрытые запросы, которые вылезают в самых неожиданных местах. Отладка производительности превращается в охоту на призраков. И можно нарваться на циклические зависимости, когда сущности начинают подгружать друг друга до скончания времён.

Советы от бывалого, чтобы не обосраться:

• Юзай AsNoTracking(), если данные только читаешь и не собираешься менять. Сэкономишь кучу памяти и процессора, потому что контекст перестанет за ними следить, как параноик.
• Фильтруй прямо в Include (с EF Core 5.0 можно). Зачем тащить все посты, если нужны только опубликованные?

  var blog = context.Blogs
      .Include(b => b.Posts.Where(p => p.IsPublished)) // Только то, что надо
      .FirstOrDefault(b => b.Id == blogId);

• Смотри в сторону проекций (Select). Часто тебе не нужна вся сущность с кучей полей, а только парочка. Зачем тогда городить огород?

  var blogData = context.Blogs
      .Where(b => b.Id == blogId)
      .Select(b => new {
          b.Title,
          PostTitles = b.Posts.Select(p => p.Title).ToList() // Только заголовки постов
      }).FirstOrDefault();

  Это как заказать в ресторане только стейк, а не целого быка с фермой.

Короче, думай головой, что тебе нужно, и не ленись писать нормальные запросы. А то потом ночью будешь разгребать алёрты по производительности и материться на свою же лень.