Van EF6 naar EF Core: wat er verandert, wat er breekt en hoe u het veilig doet

In de datalaag gaat een .NET-modernisering stilletjes mis. De schermen zien er hetzelfde uit, de build is groen, en een query die vroeger een bestelling met haar regels laadde, laadt nu de bestelling zonder regels. Microsoft is er duidelijk over: EF Core is een volledige herschrijving van Entity Framework, en een direct upgradepad vanaf EF6 is er niet.

Het goede nieuws: u hoeft niet alles tegelijk te doen.

Moet u nu overstappen?

Niet per se. EF6 draait ook op modern .NET: versie 6.5.2, uitgebracht in april 2026, is compatibel met .NET 10. EF Core daarentegen draait alleen op modern .NET, niet op .NET Framework. Daaruit volgt de veilige volgorde:

1. Zet de applicatie over van .NET Framework naar .NET 10 en houd EF6.
2. Stap daarna over van EF6 naar EF Core, onderdeel voor onderdeel.

Twee grote wijzigingen in één release maken het lastig om te zien wat een probleem veroorzaakte. Eén tegelijk houdt elke stap toetsbaar. Hoe u de eerste stap aanpakt, leest u in het artikel over migratie van .NET Framework naar .NET 10.

Waarom überhaupt naar EF Core als EF6 blijft werken? Omdat alle nieuwe ontwikkeling in EF Core gebeurt en EF6 geen nieuwe functies meer krijgt. In de praktijk betekent dat betere performance, bulkwijzigingen en -verwijderingen zonder data in het geheugen te laden (ExecuteUpdate, ExecuteDelete) en de tooling waar de rest van .NET op gebouwd is. Microsoft noemt een klant bij wie een zware query na de overstap 40 keer minder belasting gaf, dankzij query splitting.

De volgorde die werkt

1. Stap 1Inventarisatie van de datalaag
2. Stap 2EF6 op .NET 10
3. Stap 3EF Core onderdeel voor onderdeel
4. Stap 4EF6 verwijderen

Stap 3 kan omdat EF6 en EF Core naast elkaar in dezelfde applicatie kunnen draaien. Bestellingen kunnen naar EF Core terwijl de facturatie nog op EF6 draait, en elk onderdeel gaat apart naar productie.

De inventarisatie in stap 1 beantwoordt de vragen die de inspanning bepalen:

• Staat het model in een EDMX-bestand uit de designer, of in code?
• Leunt de code op lazy loading?
• Hoeveel ruwe SQL, Entity SQL en stored procedures zijn er?
• Welke queries zijn bedrijfskritisch: facturatie, voorraad, salarissen?
• Zijn er integratietests tegen een echte database?

Verschillen die het gedrag veranderen zonder foutmelding

De meeste verschillen verschijnen als compileerfout, en dat zijn de makkelijke. Deze compileren en gedragen zich toch anders:

In EF6	In EF Core	Wat te doen
Lazy loading werkt met virtuele navigatie-eigenschappen	Uit, tenzij u het pakket Microsoft.EntityFrameworkCore.Proxies toevoegt en UseLazyLoadingProxies() aanroept	Laad gerelateerde data expliciet met Include, of zet proxies bewust aan
Sommige C#-functies worden naar SQL vertaald	Niet allemaal; een onvertaalbare expressie geeft pas tijdens het draaien een fout	Doorloop elk querypad in tests, niet voor het eerst in productie
Wijzigingsdetectie over de hele graaf, vaak	Per entiteit, en minder vaak	Controleer code die entiteiten wijzigt en op automatische detectie rekent
Verweesde onderliggende rijen blijven bestaan	Afhankelijke rijen zonder ouder worden verwijderd	Controleer relaties waarin kinderen hun ouder kunnen verliezen
Data annotations worden bij opslaan gevalideerd	Geen validatie bij opslaan	Valideer in de applicatie voor het opslaan

Lazy loading controleert u als eerste. In EF6 laadt deze code de orderregels bij de eerste toegang. In EF Core zonder proxies is order.Lines gewoon niet geladen, en het totaal klopt niet, zonder enige foutmelding:

var order = db.Orders.Single(o => o.Id == id);
// EF6 laadt hier de regels. EF Core zonder proxies niet.
var total = order.Lines.Sum(l => l.Amount);

Expliciet laden is duidelijker en meestal ook sneller:

var order = db.Orders
    .Include(o => o.Lines)
    .Single(o => o.Id == id);

Wat er simpelweg niet is

• EDMX. EF Core heeft geen designer en leest geen EDMX-bestanden. In plaats daarvan wordt het model gegenereerd uit de bestaande database en vanaf dan in code onderhouden:

  dotnet ef dbcontext scaffold "Server=...;Database=Shop;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer

• Entity SQL en ObjectContext. Queries in Entity SQL gaan naar LINQ of ruwe SQL, en code die via IObjectContextAdapter bij de ObjectContext komt, moet herschreven worden.

• De migratiegeschiedenis. EF Core kan EF6-migraties niet voortzetten. Pas de laatste EF6-migratie toe, maak een nieuwe eerste migratie in EF Core en ga van daaruit verder. De database en de data blijven zoals ze zijn.

• Database-initializers en automatische migraties. Schemawijzigingen lopen via expliciete migraties.

Ruwe SQL werkt nog steeds, met veiligere standaarden. FromSql maakt van geïnterpoleerde waarden SQL-parameters:

var orders = await db.Orders
    .FromSql($"EXECUTE dbo.GetOpenOrders {customerId}")
    .ToListAsync();

Hoe u test dat de data niet veranderd is

“Het compileert” bewijst hier niets, en de gids van Microsoft zegt hetzelfde. Wat werkt:

1. Vergelijk de SQL. Log de SQL die EF6 en EF Core voor de kritieke queries versturen, en vergelijk. EF Core laat die zien met ToQueryString() of LogTo.
2. Test tegen een echte database, niet tegen een in-memory database. Verschillen in laden en verwijderen zie je pas met echte tabellen en relaties.
3. Vergelijk de resultaten. Totalen en aantallen uit facturatie, voorraad of salarissen, voor en na, op dezelfde kopie van de productiedata.
4. Release onderdeel voor onderdeel, en houd de eerste dagen fouten en trage queries in productie in de gaten.

Hoe lang het duurt

Ruwe schattingen, als de applicatie al op modern .NET draait:

• een klein model, geconfigureerd in code, met weinig ruwe SQL: een paar dagen
• een typische bedrijfsapplicatie met een EDMX-model, lazy loading en stored procedures: 2 tot 6 weken
• een groot systeem met honderden entiteiten, Entity SQL en zonder tests: 2 tot 4 maanden, onderdeel voor onderdeel, naast de normale ontwikkeling

De mapping zelf is zelden het trage deel. Dat zijn de gedragsverschillen, en de tests die laten zien dat ze zijn opgelost.

Draait de datalaag eenmaal op EF Core, dan zijn de meest voorkomende performanceproblemen in EF Core het volgende om te controleren.

Hoe wij werken

ProCoding is een .NET-studio uit Split, Kroatië, en in de datalaag brengen we veel tijd door: EF Core-performance, migraties en het overnemen van systemen waar niemand aan wil komen. We beginnen met een inventarisatie van uw datalaag, stellen de volgorde voor en zetten onderdeel voor onderdeel over, met tests die laten zien dat de data niet veranderd is. Zelf, met uw team of als freelance .NET developer in uw team. Meer over het moderniseren van oudere .NET-applicaties op onze pagina over Blazor en migratie. De eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• Port from EF6 to EF Core, Microsoft Learn
• Detailed cases for porting from EF6 to EF Core, Microsoft Learn
• Port an EF6 EDMX-based model to EF Core, Microsoft Learn
• What’s new in EF6, Microsoft Learn
• Lazy loading of related data, Microsoft Learn
• Client vs. server evaluation, Microsoft Learn