3 motivi per utilizzare la prima progettazione del codice con Entity Framework
1) Meno cruft, meno gonfia
L'uso di un database esistente per generare un file di modello .edmx e i modelli di codice associati si traducono in un enorme mucchio di codice generato automaticamente. Sei implorato di non toccare mai questi file generati per non rompere qualcosa o le tue modifiche verranno sovrascritte sulla generazione successiva. Anche il contesto e l'inizializzatore sono bloccati insieme in questo pasticcio. Quando è necessario aggiungere funzionalità ai modelli generati, come una proprietà di sola lettura calcolata, è necessario estendere la classe del modello. Questo finisce per essere un requisito per quasi tutti i modelli e si finisce con un'estensione per tutto.
Con il codice prima i tuoi modelli codificati a mano diventano il tuo database. I file esatti che stai creando sono ciò che genera la progettazione del database. Non ci sono file aggiuntivi e non è necessario creare un'estensione di classe quando si desidera aggiungere proprietà o qualsiasi altra cosa che il database non debba conoscere. Puoi semplicemente aggiungerli nella stessa classe purché segua la sintassi corretta. Diamine, puoi anche generare un file Model.edmx per visualizzare il tuo codice se vuoi.
2) Maggiore controllo
Quando si avvia DB per primi, si è in balia di ciò che viene generato per i propri modelli da utilizzare nella propria applicazione. Occasionalmente la convenzione di denominazione è indesiderabile. A volte le relazioni e le associazioni non sono proprio quello che vuoi. Altre volte relazioni non transitorie con caricamento lento causano il caos nelle risposte dell'API.
Sebbene ci sia quasi sempre una soluzione ai problemi di generazione del modello in cui potresti imbatterti, andare al primo codice ti offre un controllo completo e accurato sin dall'inizio. Puoi controllare ogni aspetto sia dei tuoi modelli di codice sia della progettazione del tuo database comodamente dall'oggetto business. È possibile specificare con precisione relazioni, vincoli e associazioni. È possibile impostare contemporaneamente limiti di caratteri di proprietà e dimensioni delle colonne del database. È possibile specificare quali raccolte correlate devono essere caricate con impazienza o non essere affatto serializzate. In breve, sei responsabile di più cose ma hai il pieno controllo del design della tua app.
3) Controllo versione database
Questo è grande. I database delle versioni sono difficili, ma con la prima codifica e la prima migrazione del codice, è molto più efficace. Poiché lo schema del database è completamente basato sui modelli di codice, in base alla versione che controlla il codice sorgente, si contribuisce alla versione del database. Sei responsabile del controllo dell'inizializzazione del contesto che può aiutarti a fare cose come seed di dati aziendali fissi. Sei anche responsabile della creazione delle prime migrazioni di codice.
Quando si abilitano per la prima volta le migrazioni, vengono generate una classe di configurazione e una migrazione iniziale. La migrazione iniziale è lo schema corrente o la linea di base v1.0. Da quel momento in poi aggiungerai le migrazioni che sono marcate con il timestamp ed etichettate con un descrittore per aiutare con l'ordine delle versioni. Quando si chiama add-migrazione dal gestore pacchetti, verrà generato un nuovo file di migrazione contenente tutto ciò che è cambiato nel modello di codice automaticamente in entrambe le funzioni SU () e GIÙ (). La funzione SU applica le modifiche al database, la funzione GIÙ rimuove le stesse modifiche nell'evento che si desidera ripristinare. Inoltre, è possibile modificare questi file di migrazione per aggiungere ulteriori modifiche come nuove viste, indici, procedure memorizzate e quant'altro. Diventeranno un vero sistema di controllo delle versioni per lo schema del database.
