В чем разница между подходами Code First и Database First в Entity Framework?

Слушай, давай разжую эту тему, а то народ путается постоянно, как будто это ядерная физика, а не обычная разработка.

Вот представь: ты приходишь на кухню готовить. Code First — это когда ты сначала придумываешь рецепт в голове ("щас возьму яйца, муку, сахар"), а потом уже лезешь в холодильник и шкафы за продуктами, и если чего-то нет — идешь в магазин. Ты полностью хозяин процесса, всё начинается с твоей идеи.

А Database First — это когда ты открываешь холодильник, смотришь, что там есть (залежалая колбаса, три яйца и банка огурцов), и на основе этого гениального набора уже соображаешь, какую жуткую яичницу ты сможешь из этого слепить. Ты отталкиваешься от того, что уже есть, а не от того, что хочется.

Так в чём же, блядь, разница-то?

• Кто главный? В Code First главный — твой код на C#. База данных — это просто его отражение, подчинённая сущность. Написал класс — EF побежал создавать или менять таблицы. В Database First главная — уже готовая база. Твой код — это как слепок с неё, рабское отражение.
• Миграции — твоя сила. В Code First у тебя есть эта офигенная система миграций. Добавил в класс новое свойство public int Rating { get; set; }, выполнил команду — и EF сам придумает, как добавить колонку Rating в таблицу, не сломав всё к чертям. Это мощь! В Database First с этим сложнее. Обновил базу вручную? Тебе надо идти в свой EDMX-файл (это такая дикая XML-диаграмма) и там тыкать кнопку "Update Model from Database", а потом молиться, чтобы ничего не отвалилось. Либо заново всё перегенерировать.
• Контроль. Code First — это чистое ООП. Всё через код, всё в репозитории. Database First — это работа с legacy, когда база живёт своей жизнью, а ты под неё подстраиваешься.

Пример Code First (Когда ты — бог и царь)

// 1. Вот твоя сущность, придуманная с нуля
public class Blog
{
    public int BlogId { get; set; } // Это будет первичный ключ, EF догадается
    public string Url { get; set; } // Это будет колонка типа nvarchar(max)
    public List<Post> Posts { get; set; } // А вот это намекнет EF на связь один-ко-многим
}

// 2. Контекст — твой главный проводник в мир БД
public class BloggingContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; } // Говоришь EF: "Следи за этими блогами!"
}

// 3. Магия! При первом запуске EF создаст БД 'BloggingContext', таблицу 'Blogs' и всё такое.
using (var db = new BloggingContext())
{
    db.Blogs.Add(new Blog { Url = "http://example.com" });
    db.SaveChanges(); // И вот он, первый запрос в свежесозданную базу!
}

Пример Database First (Когда работаешь с наследием предков)

Тут ты не пишешь код, а вызываешь волшебную команду, как шаман. Открываешь Package Manager Console и вводишь что-то страшное:

Scaffold-DbContext "Server=(localdb)mssqllocaldb;Database=Blogging;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Models

Расшифровываю: "Эй, EF, подойди-ка к базе данных на этом сервере, загляни в неё, посмотри на все эти таблицы, и нагенерируй мне в папку Models классы-клоны этих таблиц и контекст данных". И он делает! Ты получаешь готовые Blog.cs и BloggingContext.cs, но они будут выглядеть так, как их видит EF, а не так, как мечтаешь ты.

Ну и когда что брать?

• Бери Code First, если проект новый, зелёный, и ты хочешь, чтобы схема базы хранилась в гите вместе с кодом (через миграции). Это сейчас mainstream, это удобно и правильно.
• Бери Database First, если тебе дали доступ к какой-то древней, сложной, уже налаженной производственной базе, в которой 150 таблиц и триггеры на тригах сидят. Или если базой заправляет отдельный дядька-админ, который тебе просто так колонки добавлять не даст. Твоя задача в этом случае — не управлять ей, а просто аккуратно с неё считать данные.

Вот и вся философия. Не усложняй. Хочешь творить — Code First. Работаешь с готовым — Database First. Всё остальное — просто детали реализации, ебать.