DbContext-livscykeln

Yay! Nu ska vi kika på hur en DbContext lever sitt liv – från att den skapas tills den städar upp efter sig. Genom att förstå livscykeln undviker vi minnesläckor, concurrency-problem och slöseri med anslutningar.

TL;DR

Skapa DbContext så sent som möjligt, använd den kortvarigt (per request/enhet av arbete) och låt beroendeinjektion hantera den åt dig.

Ett kort liv – av goda skäl

• En DbContext kapslar in en databasanslutning och en “change tracker”.
• Change trackern håller koll på allt som laddas in/ändras.
• Ju längre kontexten lever, desto mer växer trackern → sämre prestanda.
• Därför: skapa kontexten per “scope” (t.ex. per HTTP-request eller per CLI-kommando).

Registrering i ASP.NET Core

builder.Services.AddDbContext<SchoolContext>(options =>
    options.UseSqlite("Data Source=school.db"));

• Som standard registreras kontexten som Scoped (en instans per request).
• Det är perfekt för webbappar – request in, jobba klart, stäng anslutningen.

Konsolapp eller test?

using var context = new SchoolContext(options);

// Gör arbete
var students = context.Students.ToList();

• Skapa kontexten i en using-block.
• Alternativt använd DbContextOptionsBuilder för att konfigurera i testkod.

Vanliga fallgropar

• Singleton-kontext: håller anslutningar öppna, trackern växer, concurrency-problem.
• Delad kontext över trådar: en DbContext är inte trådsäker – skapa nya per tråd.
• Glömma Dispose: i konsolapp → anslutningen stängs inte → låsta filer (SQLite).

När behöver jag långlivad kontext?

Sällan! Men batchjobb som kör många operationer kan skapa en kontext, arbeta i små block och kalla context.ChangeTracker.Clear() mellan blocken.

Obligatorisk Dad-joke

Varför gick DbContexten aldrig på dejt?

Den ville inte ha “long term relationships” – bara korta scopes!