Code First
What it is:
You write C# classes first, and EF generates the database from them.
Example:
public class Product{
public int Id { get; set; }
public string Name { get; set; }
}
Then EF creates a table like:
- Id
- Name
Products
How it works:
- Define models (classes)
- Use migrations to create/update DB
- EF syncs code → database
Pros:
- Full control in code
- Version control friendly (migrations)
- Great for new projects
- Clean and flexible
Cons:
- Requires migration management
- Not ideal for complex existing DBs
Database First
What it is:
You design the database first, and EF generates C# classes from it.
Workflow:
- Create tables in DB (SQL Server, etc.)
- Scaffold models using EF
Scaffold-DbContext "connection_string" Microsoft.EntityFrameworkCore.SqlServer
How it works:
- Existing DB → generate models
- EF reads schema and creates classes
Pros:
- Best for existing/legacy databases
- DB controlled by DBAs
- No need to design schema in code
Cons:
- Harder to maintain changes
- Regenerating models can overwrite changes
- Less control compared to Code First
Key Differences
| Feature | Code First | Database First |
|---|---|---|
| Starting point | C# classes | Database |
| Control | Developer (code) | Database |
| Schema updates | Migrations | DB changes + re-scaffold |
| Best for | New projects | Existing databases |
| Flexibility | High | Moderate |
When to Use What?
Use Code First:
- Building a new application
- Agile development (frequent changes)
- You want everything in code
Use Database First:
- Working with existing DB
- DB already designed/managed
- Large enterprise systems
Simple Analogy
- Code First = Write blueprint → build house
- Database First = House exists → create blueprint
Final Takeaway
Modern development (especially with Entity Framework Core):
- Mostly prefers Code First + Migrations
- But Database First is still very useful for real-world legacy systems
---------------------------------------------------------------------------------------------------
How to Update DB When Classes Change?
When you modify your C# models (add property, remove property, new class, etc.), you don’t directly update the database.
Instead, you use Migrations.
Step-by-step
1. Change your model
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
// NEW FIELD
public decimal Price { get; set; }
}
2. Add a Migration
Add-Migration AddPriceToProduct
EF generates a migration file like:
migrationBuilder.AddColumn<decimal>(
name: "Price",
table: "Products",
nullable: false,
defaultValue: 0m);
3. Update Database
Update-Database
This applies changes to DB.
What Happens to Existing Data?
Good news: Data is usually retained
EF migrations are incremental, not destructive (unless you explicitly make them so).
Case-by-case behavior
➤ Adding a new column
- Existing data stays
-
New column gets:
- Default value OR
- NULL (if nullable)
public decimal? Price { get; set; } // nullable → safe
➤ Adding NON-nullable column
- Must provide default value OR migration will fail
public decimal Price { get; set; } // requires default
➤ Renaming a column
EF might:
- Drop old column ❌
- Create new column ❌
👉 This can cause data loss unless handled manually.
✔ Fix:
migrationBuilder.RenameColumn(
name: "OldName",
table: "Products",
newName: "NewName");Note: Using rename retain the column data
➤ Deleting a property
- Column is dropped → data lost
➤ Adding a new table (new class)
public class Category
{
public int Id { get; set; }
public string Name { get; set; }
}
👉 Migration will:
- Create new table
- Existing tables/data remain unchanged
3. How EF Keeps Track
EF uses a special table:
👉 __EFMigrationsHistory
- Tracks applied migrations
- Ensures only new changes are applied
4. Best Practices
1. Always use migrations
Never manually change DB in Code First workflow
2. Make new fields nullable initially
public string? NewColumn { get; set; }
Then later enforce required
3. Review migration code before applying
Check for:
- Drops ❌
- Renames ❌
- Data loss risks
4. Use Rename instead of Drop/Create
Prevents data loss
5. Backup DB in production
Always before running:
Update-Database
5. Simple Flow Summary
Change Model → Add-Migration → Review Migration → Update-Database
Key Takeaway
- EF does NOT overwrite DB
- It applies incremental schema changes
- Existing data is safe unless you explicitly break it
