Blazor i .NET

Prelazak s EF6 na EF Core: što se mijenja, što puca i kako to napraviti sigurno

Izravne nadogradnje s Entity Frameworka 6 na EF Core nema. Redoslijed koji radi, razlike koje tiho mijenjaju vaše podatke i kako ih testirati.

Vlado Pandžić

Vlado Pandžić · Osnivač · Senior .NET arhitekt
Objavljeno · 6 min čitanja

Sloj podataka mjesto je gdje modernizacija .NET aplikacije tiho pođe po zlu. Ekrani izgledaju isto, build prolazi, a upit koji je prije učitavao narudžbu sa stavkama sad učita narudžbu bez njih. Microsoft je tu jasan: EF Core je Entity Framework prepisan od nule i izravnog puta nadogradnje s EF6 nema.

Dobra vijest je da ne morate sve odjednom.

Morate li prijeći odmah?

Ne nužno. EF6 radi i na modernom .NET-u: verzija 6.5.2, izašla u travnju 2026., kompatibilna je s .NET-om 10. EF Core, s druge strane, radi samo na modernom .NET-u, a ne na .NET Frameworku. Iz toga slijedi siguran redoslijed:

  1. Aplikaciju prebacite s .NET Frameworka na .NET 10 i zadržite EF6.
  2. Zatim prijeđite s EF6 na EF Core, dio po dio.

Dvije velike promjene u istoj isporuci znače da se ne zna što je uzrokovalo problem. Jedna po jedna drži svaki korak provjerljivim. Kako pristupiti prvom koraku, opisali smo u članku o prelasku s .NET Frameworka na .NET 10.

Zašto uopće prelaziti na EF Core ako EF6 i dalje radi? Zato što se sav novi razvoj događa u EF Coreu, a EF6 više ne dobiva nove mogućnosti. U praksi to znači bolje performanse, masovne izmjene i brisanja bez učitavanja podataka u memoriju (ExecuteUpdate, ExecuteDelete) i alate oko kojih je izgrađen ostatak .NET-a. Microsoft navodi klijenta kojem je nakon prelaska jedan težak upit postao 40 puta jeftiniji, zahvaljujući dijeljenju upita.

Redoslijed koji radi

  1. 1. korakPopis stanja sloja podataka
  2. 2. korakEF6 na .NET-u 10
  3. 3. korakEF Core dio po dio
  4. 4. korakUklanjanje EF6

Treći korak je moguć jer EF6 i EF Core mogu raditi jedan uz drugoga u istoj aplikaciji. Narudžbe mogu prijeći na EF Core dok fakturiranje još radi na EF6, a svaki dio ide u produkciju zasebno.

Popis u prvom koraku odgovara na pitanja o kojima ovisi trud:

  • Je li model u EDMX datoteci iz dizajnera ili u kodu?
  • Oslanja li se kod na lazy loading?
  • Koliko ima sirovog SQL-a, Entity SQL-a i stored procedura?
  • Koji su upiti poslovno kritični: fakturiranje, zalihe, plaće?
  • Postoje li integracijski testovi na pravoj bazi?

Razlike koje mijenjaju ponašanje bez ijedne greške

Većina razlika pojavi se kao greška pri kompajliranju, i to su one lakše. Ove se kompajliraju, a ipak se ponašaju drugačije:

U EF6 U EF Coreu Što napraviti
Lazy loading radi s virtualnim navigacijskim svojstvima Isključen, osim ako dodate paket Microsoft.EntityFrameworkCore.Proxies i pozovete UseLazyLoadingProxies() Povezane podatke učitajte izričito s Include ili proxyje uključite svjesno
Neke C# funkcije prevode se u SQL Ne sve; izraz koji se ne može prevesti baca grešku tek u radu Prođite svaki upit u testovima, ne prvi put u produkciji
Otkrivanje promjena ide preko cijelog grafa, često Po entitetu, i rjeđe Provjerite kod koji mijenja entitete i oslanja se na automatsko otkrivanje
Siročad, retci djece bez roditelja, ostaju Zavisni retci bez roditelja se brišu Provjerite veze u kojima djeca mogu izgubiti roditelja
Data annotations se provjeravaju pri spremanju Nema provjere pri spremanju Validirajte u aplikaciji prije spremanja

Lazy loading je prvi koji treba provjeriti. U EF6 ovaj kod učita stavke narudžbe pri prvom pristupu. U EF Coreu bez proxyja order.Lines jednostavno nije učitan, i zbroj je pogrešan bez ikakve greške:

var order = db.Orders.Single(o => o.Id == id);
// EF6 ovdje učita stavke. EF Core bez proxyja ne učita.
var total = order.Lines.Sum(l => l.Amount);

Izričito učitavanje je jasnije, a obično i brže:

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

Čega jednostavno nema

  • EDMX. EF Core nema dizajner i ne čita EDMX datoteke. Umjesto toga model se generira iz postojeće baze i od tada održava u kodu:

    dotnet ef dbcontext scaffold "Server=...;Database=Shop;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer
  • Entity SQL i ObjectContext. Upiti pisani u Entity SQL-u prelaze u LINQ ili sirovi SQL, a kod koji do ObjectContexta dolazi preko IObjectContextAdapter treba prepisati.

  • Povijest migracija. EF Core ne može nastaviti EF6 migracije. Primijenite zadnju EF6 migraciju, napravite novu početnu migraciju u EF Coreu i nastavite od nje. Baza i podaci ostaju kakvi jesu.

  • Inicijalizatori baze i automatske migracije. Promjene sheme idu kroz izričite migracije.

Sirovi SQL i dalje radi, uz sigurnije zadane postavke. FromSql interpolirane vrijednosti pretvara u SQL parametre:

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

Kako provjeriti da se podaci nisu promijenili

“Kompajlira se” ovdje ne dokazuje ništa, a to kaže i sam Microsoftov vodič. Ono što radi:

  1. Usporedite SQL. Zabilježite SQL koji EF6 i EF Core šalju za kritične upite i usporedite ga. EF Core ga pokazuje preko ToQueryString() ili LogTo.
  2. Testirajte na pravoj bazi, a ne na bazi u memoriji. Razlike u učitavanju i brisanju vide se tek na pravim tablicama i vezama.
  3. Usporedite rezultate. Zbrojeve i brojke iz fakturiranja, zaliha ili plaća, prije i poslije, na istoj kopiji produkcijskih podataka.
  4. Isporučujte dio po dio i prvih dana pratite greške i spore upite u produkciji.

Koliko traje

Okvirni rasponi, kad aplikacija već radi na modernom .NET-u:

  • mali model konfiguriran u kodu, s malo sirovog SQL-a: nekoliko dana
  • tipična poslovna aplikacija s EDMX modelom, lazy loadingom i stored procedurama: 2 do 6 tjedana
  • velik sustav sa stotinama entiteta, Entity SQL-om i bez testova: 2 do 4 mjeseca, dio po dio, uz redovni razvoj

Samo mapiranje rijetko je spori dio. Spori dio je pronaći razlike u ponašanju i napisati testove koji dokazuju da su riješene.

Kad sloj podataka radi na EF Coreu, sljedeće što vrijedi provjeriti su najčešći problemi s performansama EF Corea.

Kako mi radimo

ProCoding je .NET studio iz Splita, a sloj podataka je mjesto na kojem provodimo puno vremena: performanse EF Corea, migracije i preuzimanje sustava koje nitko ne želi dirati. Krećemo od popisa stanja vašeg sloja podataka, predložimo redoslijed i prebacujemo dio po dio, uz testove koji pokazuju da se podaci nisu promijenili. Sami, s vašim timom ili kao freelance .NET developer u vašem timu. Više o modernizaciji starijih .NET aplikacija na našoj stranici o Blazoru i migraciji. Prvi korak je besplatan razgovor od 30 minuta.

Izvori

Ovaj članak služi općem informiranju i nije pravni, porezni, financijski ni drugi stručni savjet. Scenariji, primjeri i izračuni su ilustrativni. Uvjeti korištenja i odricanje od odgovornosti.

Povezani članci

© 2026 ProCoding — Sva prava pridržana.Impresum i privatnostUvjeti korištenjaSplit, Hrvatska