Port från EF6 till EF Core – Databas som sanningskälla

Om du använder databasen som sanningskälla handlar uppgraderingen främst om att åtgärda eventuella ändringar i formen på entiteter som genereras. Stegen för att migrera är:

1. Välj en tidpunkt för att modellera databasen.
2. Se till att dina EF6-projekt är uppdaterade och synkroniserade med databasen.
3. Skapa EF Core-projektet.
4. Använd scaffolding-verktygen för att reverse-engineera din databas till kod.
5. Kontrollera att de EF Core-genererade klasserna är kompatibla med din kod.
6. För undantag ändrar du antingen de genererade klasserna och uppdaterar modellkonfigurationen eller anpassar koden till modellen.

Observera att även om EF Core för närvarande genererar allt som behövs för att framgångsrikt skapa en kopia av databasen, är mycket av koden onödig för database-first-metoden. En korrigering för detta spåras i Ärende #10890. Saker som du på ett säkert sätt kan ignorera när det inte behövs är: sekvenser, villkorsnamn, icke-unika index och indexfilter.

Hantera schemaändringar

När databasen är sanningskälla hämtar EF Core schemainformation från databasen istället för att skicka den genom migreringar. Det vanliga arbetsflödet är att köra det omvända ingenjörssteget igen när databasschemat ändras. En omfattande testsvit är värdefull för den här metoden eftersom du kan automatisera förberedelseprocessen och verifiera ändringarna genom att köra dina tester.

Tips för att hantera modellskillnader

Av olika skäl kanske du vill att din C#-domänmodell ska formas på ett annat sätt än den som genereras i omvänd teknik. I många fall innebär detta att manuellt uppdatera koden som genereras automatiskt efter varje schemaändring. Ett sätt att förhindra extra arbete när koden återskapas är att använda partiella klasser för din DbContext och relaterade entiteter. Sedan kan du hålla kod relaterad till affärslogik och egenskaper som inte spåras i databasen i en separat uppsättning klassfiler som inte skrivs över.

Om din modell skiljer sig avsevärt från den genererade, men inte ändras ofta, är ett alternativ att överväga att använda repositories mönster som en adapter. Lagringsplatsen kan använda de EF Core-skapade klasserna och publicera de anpassade klasser som du använder. Detta kan minska effekten av ändringar genom att isolera dem till lagringsplatskoden, i stället för att behöva utföra en programomfattande refaktorisering varje gång schemat ändras.

Du kanske vill överväga ett alternativt arbetsflöde och följa steg som liknar hybridmetoden. I stället för att generera en ny uppsättning klasser varje gång anger du specifika tabeller för att endast generera nya klasser. Du behåller befintliga klasser "i befintligt läge" och lägger direkt till eller tar bort egenskaper som har ändrats. Sedan uppdaterar du modellkonfigurationen för att åtgärda eventuella ändringar i hur databasen mappar till dina befintliga klasser.

Anpassa kodgenereringen

EF Core 6 stöder för närvarande inte anpassning av den genererade koden. Det finns lösningar från tredje part som EF Core Power Tools som är tillgängliga. En lista över aktuella communityverktyg och tillägg finns i: EF Core Tools och Extensions.

Granska slutligen den detaljerade listan över skillnader mellan EF6 och EF Core för att åtgärda eventuella återstående problem med portning.