EF Core

DbContext is the session with the database: it holds the model, the connection and the change tracker, and SaveChanges flushes the pending edits in one go. Each DbSet<T> property is the queryable collection of one entity type and the entry point for Add and Remove on it.

A tracked query puts each entity into the ChangeTracker with a snapshot of its original values and resolves identity, so one key yields one instance. SaveChanges diffs the snapshots against the current values to build the UPDATEs. AsNoTracking skips the snapshot and identity resolution — cheaper reads, but the entities cannot be saved back.

builder.Services.AddDbContext<AppDbContext>(...) registers the context and configures its provider. The registration is scoped: the container builds one instance per request and disposes it with the scope. A service takes AppDbContext as a constructor parameter, never newing one.

It accumulates every add, update and delete made to its tracked entities and commits them together: one SaveChanges opens a transaction, writes them all, and rolls everything back on failure. That is why AddDbContext registers it as scoped — one context per request means one unit of work per request, disposed with the scope.

One query loads N parents, and then touching each parent's navigation issues one more query per parent — N+1 round trips instead of one. Load the related data in the same query: Include for the whole graph, or a Select projection that pulls only the columns you need. Lazy loading is the usual cause, so turn it off in an API.

Eager loading pulls the relation inside the original query, with Include. Explicit loading fetches it later on demand, through an Entry(...).Collection(...).Load() call — one extra round trip that you asked for. Lazy loading fetches it the moment a proxied navigation is read: implicit, and the classic source of N+1.

It builds the model from your DbContext, diffs it against the model snapshot left by the previous migration, and generates a C# migration class with Up and Down plus an updated snapshot. It never touches the database — the SQL runs later, on dotnet ef database update or a Migrate() call at startup.

Every query is compiled: the provider walks the expression tree, computes a cache key from it, and looks the plan up in its query cache. A compiled query does that once and hands you a delegate, so the tree walk and the cache lookup vanish from every later call. It pays off for hot, frequently executed queries of a fixed shape — the structure cannot vary per call.

Configure the property with IsRowVersion(): the value read with the entity is added to the WHERE clause of the generated UPDATE. If another transaction changed the row meanwhile, the version no longer matches, zero rows are affected, and SaveChanges throws DbUpdateConcurrencyException. You then reload the current values and retry, merge, or surface the conflict.

The log shows one query for the 50 orders and then one query per order for its lines — 51 round trips. That is N+1, caused by a navigation resolved lazily inside the loop; each command is fast, so the SQL is not the problem, the count of them is. Load the lines in the same query with Include or a Select projection, turn lazy loading off, and add AsNoTracking to drop the tracking cost on a read-only endpoint.

Never rename in place — expand, then contract, over three deploys. Deploy 1 adds a nullable FullName, writes both columns and still reads Name. Backfill the old rows in small batches so no long lock is taken. Deploy 2 reads FullName and still writes both, once the backfill is verified. Deploy 3 makes FullName non-nullable and drops Name. Every step is additive, works with both builds live, and can be rolled back on its own.