Entity Framework Core Internals

By the end of this lesson you'll understand how EF Core turns your C# objects into SQL — how the change tracker watches your edits, how LINQ becomes a query, why execution is deferred, and how to dodge the performance traps (N+1, over-tracking) that bite real apps. You'll be able to reason about exactly what database work your code triggers.

1. DbContext & DbSet<T>

A DbContext is your session with the database — one short-lived object that opens a connection, holds your data, and tracks changes. Inside it you expose one DbSet<T> per table; a DbSet<Product> behaves like a queryable collection of Product objects backed by the Products table. Each entity is just a plain C# class whose properties map to columns. Read this worked example, then you'll model the same shape in runnable C#.

using System;
using System.Collections.Generic;
using Microsoft.EntityFrameworkCore;

// ⚠️ This is REAL EF Core code. EF Core needs a database engine, so it does
// NOT run in this in-browser editor — read it and study the comments instead.
// Every "Expected output" below is the SQL EF Core would generate, or the rows.

// An ENTITY is a plain C# class that maps to one table row.
public class Product
{
    public int Id { get; set; }                 // convention: 'Id' = primary key
    public
...

Your turn — and this one runs. A DbSet<T> is, at heart, just a collection you add to and read from, so here you'll model it with a List<Product>. Fill in the two ___ blanks, then run it.

using System;
using System.Collections.Generic;

// 🎯 YOUR TURN — this is PLAIN C# that MODELS how a DbContext works:
// a DbSet<T> is just a collection of entities, and SaveChanges writes them.
// Fill in the ___ blanks, then press "Try it Yourself".

// An entity = a plain class (like an EF Core entity).
class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = "";
}

// A tiny "context": a DbSet is modelled here as a List<Product>.
class FakeContext
{
    // 1) M
...

2. Change Tracking & EntityState

When you load an entity, EF Core's change tracker takes a snapshot and labels it Unchanged. As you edit, add, or remove entities, it updates each one's EntityState — the margin note from our analogy. You never set these states by hand for normal edits; the tracker watches your property assignments and infers them. You can inspect any entity's state with db.Entry(entity).State. This is what lets SaveChanges() emit the minimal SQL — an UPDATE touches only the columns you actually changed.

using System;
using Microsoft.EntityFrameworkCore;

// Real EF Core — read only. The change TRACKER watches every entity you load
// and remembers its EntityState so SaveChanges knows what SQL to emit.
class Program
{
    static void Main()
    {
        using var db = new ShopContext();

        // 1) Load an entity. EF starts tracking it as Unchanged.
        var product = db.Products.First();
        Console.WriteLine(db.Entry(product).State);   // Unchanged

        // 2) Change a property. 
...

Now you model it. Real EF Core stores an EntityState per entity; here you'll define that enum and flip a state yourself. Fill in the two ___ blanks, then run it.

using System;

// 🎯 YOUR TURN — model change tracking yourself in plain C#.
// EF Core stores an EntityState per entity; here YOU flip the state by hand.

// 1) Define an enum named EntityState with three states:
//    Added, Modified, Unchanged.
enum EntityState { ___ }   // 👉 list them comma-separated: Added, Modified, Unchanged

// A tracked entity = the entity plus its current state.
class TrackedProduct
{
    public string Name { get; set; } = "";
    public EntityState State { get; set; 
...

3. Query Translation & Deferred Execution

When you chain LINQ methods on a DbSet<T>, EF Core doesn't run anything yet — it builds an expression tree, a description of the query. This is deferred execution: the SQL is generated and sent only when you actually enumerate the result, with ToList(), a foreach, First(), Count(), and so on. EF then translates your Where into a SQL WHERE, your OrderBy into ORDER BY, and your Select into a column list — running the filtering on the database server, not in your app's memory.

using System;
using System.Linq;
using Microsoft.EntityFrameworkCore;

// Real EF Core — read only. EF TRANSLATES your LINQ into SQL, and the query
// is DEFERRED: nothing hits the database until you enumerate it.
class Program
{
    static void Main()
    {
        using var db = new ShopContext();

        // Building a query does NOT run it — no SQL yet. 'query' is a recipe.
        var query = db.Products
            .Where(p => p.Price > 100)        // -> WHERE "Price" > 100
            .Or
...

// Read-only list for a web page — no edits coming, so don't track:
var list = db.Products.AsNoTracking().ToList();

// Editing flow — DO track, so SaveChanges() sees the change:
var p = db.Products.First();   // tracked
p.Price = 12.50m;              // tracker notes "Modified"
db.SaveChanges();             // emits the UPDATE

4. SaveChanges Batching

You can add, edit, and delete dozens of entities, and nothing touches the database until you call SaveChanges(). At that point EF walks the change tracker, collects every non-Unchanged entity, and sends the work as one batched round-trip inside a transaction — so it's all-or-nothing. Batching matters: a single trip across the network is dramatically faster than one trip per row. The change-tracking worked example above shows three different operations (UPDATE, INSERT, DELETE) all flushed by a single SaveChanges() call.

using System;
using System.Linq;
using Microsoft.EntityFrameworkCore;

// The N+1 PROBLEM — the single most common EF Core performance bug.
class Program
{
    static void Main()
    {
        using var db = new ShopContext();

        // ❌ BAD: 1 query for the products, then 1 MORE query per product to
        //         load its Reviews (lazy loaded on access). 100 products = 101
        //         round-trips to the database. That is the "N+1".
        var products = db.Products.ToList();    
...

using System;
using System.Collections.Generic;
using System.Linq;

// 🎯 MINI-CHALLENGE: Build an in-memory repository (a mini "DbSet").
// A repository wraps a List<T> and exposes Add / Find / Remove — exactly the
// shape EF Core's DbSet<T> gives you, minus the database.
//
// 1. Give ProductRepository a private List<Product> field called 'items'.
// 2. Add(Product p)            -> add p to the list.
// 3. Find(int id)             -> return the product with that Id, or null.
// 4. Remove(int 
...