Что такое Entity Framework Core?

Слушай, ну вот объясняю тебе, как работает эта штука — Entity Framework Core, или EF Core, как его нормальные люди зовут. Представь себе, что у тебя есть куча объектов в коде на C#, и тебе надо их в базу данных запихнуть. Так вот, эта ORM-ка — она как такой умный переводчик-грузчик, который берёт твои классы и тащит их прямиком в таблицы SQL, чтобы тебе самому не приходилось писать эти километровые запросы руками. Удобно, блядь, если честно.

Что он умеет, этот зверь?

• LINQ-запросы: Ты пишешь на своём родном C#, типа Where(b => b.Rating > 3), а он уже сам, хитрая жопа, превращает это в правильный SQL. Магия, ёпта!
• Отслеживание изменений: Загрузил ты объект из базы, поменял в нём поле — он это запомнил. Когда скажешь SaveChanges(), он сам сообразит, какой UPDATE нужно выстрелить. Лень — двигатель прогресса, я тебе скажу.
• Миграции: Это вообще песня. Схему базы (таблицы, столбцы) ты описываешь кодом, а EF Core генерит скрипты для её обновления. То есть версионирование базы, как кода. Красота, хотя иногда и головная боль, если накосячить.
• Кучу баз данных понимает: SQL Server, PostgreSQL, SQLite — подсовывай нужного провайдера и работай. Не универсальная отвёртка, конечно, но штука полезная.
• Загрузка связей: Может тянуть связанные данные сразу (жадно), по требованию (лениво) или явно, когда скажешь. Главное — не нахерачить N+1 запрос, а то производительность накроется медным тазом.

Смотри, как это выглядит в жизни, на простом примере:

1. Сначала описываешь свои сущности и контекст — это как менеджер базы.

// Это у нас блог, типа класс
public class Blog
{
    public int Id { get; set; }
    public string Url { get; set; }
    public int Rating { get; set; }
    public List<Post> Posts { get; set; } // А это связь на посты, навигационное свойство
}

// А это сам контекст — мозги операции, знает про все наши таблицы
public class BloggingContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; } // Вот коллекция блогов
    public DbSet<Post> Posts { get; set; } // А вот постов

    // Тут настраиваешь, к какой базе цепляться
    protected override void OnConfiguring(DbContextOptionsBuilder options)
        => options.UseSqlServer(@"Server=(localdb)mssqllocaldb;Database=BloggingDB;Trusted_Connection=True");
}

2. А теперь используем это всё для базовых операций (CRUD):

// Добавление (Create)
using var db = new BloggingContext(); // Контекст лучше в using, чтобы ресурсы закрывал
var blog = new Blog { Url = "https://example.com", Rating = 5 };
db.Blogs.Add(blog); // Сказали EF Core: "Запомни, эту сущность надо вставить"
await db.SaveChangesAsync(); // А тут он пошёл и реально сделал INSERT. Всё.

// Чтение (Read) через LINQ
var topBlogs = await db.Blogs
    .Where(b => b.Rating > 3) // Смотри, чистый C#, а не SQL!
    .OrderByDescending(b => b.Rating)
    .ToListAsync(); // Выполнил запрос и вернул список

// Обновление (Update)
var blogToUpdate = await db.Blogs.FindAsync(1); // Нашли по id
if (blogToUpdate != null)
{
    blogToUpdate.Rating = 10; // Просто меняем свойство
    await db.SaveChangesAsync(); // EF Core видит изменение и делает UPDATE. Волшебство!
}

// Удаление (Delete)
var blogToDelete = await db.Blogs.FindAsync(2);
db.Blogs.Remove(blogToDelete); // Пометили на удаление
await db.SaveChangesAsync(); // И DELETE готов. В общем, логично.

Так когда его использовать-то, спросишь?

Идеален, когда нужно быстро сделать работающее приложение, не заморачиваясь с тонкостями SQL. Для прототипов, админок, да и многих бизнес-приложений — то, что надо. Но если у тебя высоконагруженный сервис, где каждый микрограмм производительности на счету, или там сложная аналитика, то тут EF Core может начать тупить и генерить неоптимальные запросы. В таких случаях иногда лучше взять что-то вроде Dapper (микро-ORM) или вовсе писать SQL руками, чтобы контролировать всё до последней запятой. Но для старта и в 80% случаев — EF Core твой друг, хоть и с причудами.