Porta da EF6 a EF Core - Database come origine della verità
Se si usa il database come origine della verità, l'aggiornamento comporta principalmente l'indirizzamento delle modifiche alla forma delle entità generate. I passaggi per la migrazione includono:
- Selezionare un punto nel tempo per modellare il database.
- Verificare che i progetti EF6 siano aggiornati e sincronizzati con il database.
- Creare il progetto EF Core.
- Usare gli strumenti di scaffolding per invertire il codice del database.
- Verificare che le classi generate da EF Core siano compatibili con il codice.
- Per le eccezioni, modificare le classi generate e aggiornare la configurazione del modello o adattare il codice al modello.
Si noti che anche se EF Core esegue attualmente lo scaffolding di tutti gli elementi necessari per generare correttamente una copia del database, gran parte del codice non è necessaria per l'approccio database-first. Una correzione per questa operazione viene rilevata nel problema #10890. Gli elementi che è possibile ignorare senza necessità includono: sequenze, nomi di vincoli, indici non univoci e filtri di indice.
Gestione delle modifiche dello schema
Quando il database è l'origine della verità, EF Core esegue il pull delle informazioni sullo schema dal database anziché eseguirne il push tramite migrazioni. Il flusso di lavoro tipico consiste nell'eseguire nuovamente il passaggio di reverse engineering ogni volta che lo schema del database viene modificato. Un gruppo di test completo è utile per questo approccio perché è possibile automatizzare il processo di scaffolding e verificare le modifiche eseguendo i test.
Suggerimenti per la gestione delle differenze del modello
Per vari motivi, è possibile che il modello di dominio C# venga modellato in modo diverso da quello generato in reverse engineering. In molti casi, ciò significa aggiornare manualmente il codice generato automaticamente dopo ogni modifica dello schema. Un modo per evitare ulteriori sforzi quando il codice viene rigenerato consiste nell'usare classi parziali per DbContext e le entità correlate. È quindi possibile mantenere il codice correlato alla logica di business e alle proprietà non rilevate nel database in un set separato di file di classe che non verranno sovrascritti.
Se il modello è significativamente diverso da quello generato, ma non cambia frequentemente, un'opzione da considerare è l'uso del modello di repository come adattatore. Il repository può usare le classi generate da EF Core e pubblicare le classi personalizzate usate. Ciò può ridurre l'impatto delle modifiche isolandole nel codice del repository, anziché dover eseguire un refactoring a livello di applicazione ogni volta che lo schema viene modificato.
È possibile prendere in considerazione un flusso di lavoro alternativo e seguire i passaggi simili all'approccio ibrido. Anziché generare un nuovo set di classi ogni volta, si indicano tabelle specifiche per generare solo nuove classi. Mantenere le classi esistenti "così come sono" e aggiungere o rimuovere direttamente le proprietà che sono state modificate. Aggiornare quindi la configurazione del modello per risolvere eventuali modifiche nel modo in cui il database esegue il mapping alle classi esistenti.
Personalizzare la generazione del codice
EF Core 6 attualmente non supporta la personalizzazione del codice generato. Sono disponibili soluzioni di terze parti come EF Core Power Tools . Per un elenco degli strumenti e delle estensioni della community in primo piano, vedere Strumenti ed estensioni di EF Core.
Esaminare infine l'elenco dettagliato delle differenze tra EF6 e EF Core per risolvere eventuali problemi rimanenti relativi alla conversione.
