By the end of this session, you will be able to:

• Explain what an ORM is and why Entity Framework Core is the .NET standard for database access
• Distinguish between the code-first and database-first approaches, and choose the right one for a new project
• Set up a DbContext with a PostgreSQL or SQL Server connection string
• Define entity classes and configure their properties and relationships using the Fluent API
• Register DbContext in Program.cs and verify the application starts cleanly against a real database

• An Object-Relational Mapper (ORM) maps C# classes to database tables and class properties to columns — eliminating manual SQL strings for routine operations
• Entity Framework Core is Microsoft's official ORM for .NET — it is cross-platform, open-source, and supports PostgreSQL, SQL Server, SQLite, and more through provider packages
• At runtime, EF Core translates LINQ queries written in C# into provider-specific SQL and executes them against the database
• Results are returned as tracked C# objects — EF Core watches them for changes, and a single SaveChanges() call flushes all changes to the database in one transaction
• EF Core also handles schema generation and migrations — C# class definitions become the source of truth for the database schema

• Single source of truth — the C# entity classes define the schema. There is no separate SQL script to keep in sync with the code
• Version control integration — every schema change produces a migration file checked into Git alongside the code that required the change
• Reproducible environments — any developer can clone the repo, run dotnet ef database update, and have an identical database in minutes
• Refactoring safety — renaming a property in C# produces a migration that renames the column; the change is atomic and tracked
• Team-friendly — pull requests contain both the feature code and its migration, so reviewers see exactly what the schema impact is

Three packages are needed — the core library, the design-time tooling, and the database provider:

dotnet add package Microsoft.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL

Using SQL Server instead? Replace the provider:

dotnet add package Microsoft.EntityFrameworkCore.SqlServer

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }

    public DbSet<TaskItem> Tasks => Set<TaskItem>();
    public DbSet<User> Users => Set<User>();

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<TaskItem>(entity =>
        {
            entity.HasKey(t => t.Id);
            entity.Property(t => t.Title).IsRequired().HasMaxLength(200);
            entity.Property(t => t.CreatedAt).HasDefaultValueSql("NOW()");
        });
    }
}

DbSet<T> properties expose each table as a queryable collection. OnModelCreating is called once at startup — this is where Fluent API configuration lives. The constructor receives DbContextOptions from DI, which carries the connection string and provider.

modelBuilder.Entity<TaskItem>(entity =>
{
    entity.HasKey(t => t.Id);
    entity.Property(t => t.Title).IsRequired().HasMaxLength(200);
    entity.Property(t => t.Description).HasMaxLength(2000);
    entity.Property(t => t.CreatedAt).HasDefaultValueSql("NOW()");

    entity.HasOne(t => t.User)
          .WithMany(u => u.Tasks)
          .HasForeignKey(t => t.UserId)
          .OnDelete(DeleteBehavior.Cascade);
});

IsRequired() adds a NOT NULL constraint. HasMaxLength(200) sets varchar(200) in the database — without it, EF Core defaults to text (Postgres) or nvarchar(max) (SQL Server), which cannot be indexed efficiently. HasDefaultValueSql("NOW()") lets the database populate the timestamp automatically.

Connect the Task Manager API to a real database. By the end of this lab, the application will start cleanly against a running PostgreSQL or SQL Server instance.

• EF Core is an ORM — it maps C# classes to database tables and translates LINQ queries into provider-specific SQL, eliminating manual SQL strings for routine operations
• Code-first is the standard approach — C# entity classes are the source of truth; migrations translate class changes into schema changes tracked in version control
• DbContext is the central class — it exposes DbSet<T> properties per table, manages change tracking, and is registered as a scoped service in DI
• Fluent API in OnModelCreating is the recommended way to configure constraints, indexes, default values, and relationships without polluting entity classes with attributes
• Connection strings are secrets — store them in appsettings.Development.json, add that file to .gitignore, and use environment variables or a secrets manager in production
• Migrations come next — Session 10 covers creating and applying migrations to generate and evolve the real database schema from these entity definitions

Session 10 — Migrations, CRUD & LINQ

• The AppDbContext and entity classes set up in this session are the foundation — Session 10 picks up exactly where this lab ends
• You will install the dotnet ef CLI tool, create your first migration with dotnet ef migrations add, and apply it to generate the real tables with dotnet ef database update
• The in-memory lists currently backing the Task API endpoints will be replaced with real DbSet queries — ToListAsync(), FindAsync(), AddAsync(), and SaveChangesAsync()
• LINQ filtering, ordering, and pagination will be pushed to the database layer so the SQL is efficient from the start

Wire up Entity Framework Core for the Task Manager API and connect it to a real database.

What to build:

• Install the EF Core packages and the appropriate database provider, then create AppDbContext with DbSet<TaskItem> and DbSet<User>
• Configure both entities using the Fluent API in OnModelCreating: required fields, max lengths, default values, and the foreign key relationship between TaskItem and User
• Register AppDbContext in Program.cs and store the connection string in appsettings.Development.json, adding it to .gitignore

Acceptance criteria:

• dotnet run starts the application without any EF Core-related startup exceptions
• AppDbContext has DbSet properties for both TaskItem and User, configured via the Fluent API
• All string columns have explicit HasMaxLength() calls and no column is left as unbounded text
• appsettings.Development.json is listed in .gitignore and is not committed to the repository