Processo di sviluppo per il codice First Entity Framework e SQL Server Data Tools Progetti di database

Question

Ho utilizzato molto bene i progetti database Database First Entity Framework (EDMX) e SQL Server Data Tools in combinazione con molto successo: modificare lo schema nel database e 'Aggiorna modello dal Database 'per inserirli nell'EDMX. Vedo però che Entity Framework 7 lascerà cadere il formato EDMX e sto cercando un nuovo processo che mi consenta di usare Code First in combinazione con progetti di database.

Molti dei miei processi di sviluppo e distribuzione esistenti si basano sull'avere un progetto di database che contiene lo schema. Il controllo del codice sorgente viene implementato insieme al codice e viene utilizzato per aggiornare il database di produzione completo di migrazione dei dati mediante gli script di pre e post distribuzione. Sarei riluttante a lasciar perdere.

Mi piacerebbe dividere un grande EDMX in molti modelli più piccoli come parte di questo lavoro. Ciò comporterà più modelli Code First che fanno riferimento allo stesso database.

Supponendo di disporre di un database esistente e di un progetto di database per utilizzarlo, penso che inizierei utilizzando la seguente procedura guidata per creare un set iniziale di entità e classi di contesto: lo farei per ciascuna di esse. i modelli.

Add | New Item... | Visual C# Items | Data | ADO.NET Entity Data Model | Code first from database 

Il mio problema è - dove vado da lì? Come gestisco le modifiche dello schema? Finché riesco ad aggiornare lo schema del database, posso utilizzare un'operazione di confronto dello schema per ottenere le modifiche nel progetto.

Queste sono le opzioni che sto prendendo in considerazione.

1. Apportare modifiche al database e utilizzare la procedura guidata da sopra per rigenerare. Immagino che avrei bisogno di mantenere eventuali modifiche all'entità e/o classi di contesto in classi parziali in modo che non vengano sovrascritte. Automatizzare questo con un elenco di tabelle ecc da includere sarebbe utile. Forse i modelli Powershell o T4? SqlSharpener (suggerito da Keith nei commenti) sembra che potrebbe aiutare qui. Vorrei anche dare un'occhiata a disabling all but the checks for database existence and schema compatibility qui, come suggerito da Steve Green nei commenti.
2. Apportare le modifiche nel codice e utilizzare le migrazioni per ottenere queste modifiche applicate al database. Da quello che ho capito, il fatto di non avere una mappa dei modelli pulita negli schemi di database (il mio non fare) potrebbe porre problemi. Vedo anche alcuni reclami sulla rete che le migrazioni non coprono tutti i tipi di oggetto del database - questa è stata anche la mia esperienza quando ho giocato con Code First qualche tempo fa - restrizioni uniche che penso non fossero coperte. Questo è migliorato in Entity Framework 7?
3. Apportare modifiche nel database e quindi utilizzare le migrazioni come una sorta di confronto tra codice e database. Guarda quali sono le differenze e regola il codice per adattarlo. Continua finché non ci sono differenze.
4. Apportare le modifiche manualmente sia nel codice che nel database. Ovviamente, questo non è molto allettante.

Quale di questi sarebbe il migliore? C'è qualcosa che avrei bisogno di sapere prima di provare a implementarlo? Ci sono altre opzioni migliori?

Answer 1

Quindi il percorso che abbiamo concluso è stato quello di creare alcuni modelli T4 che generano sia un DbContext che le nostre entità. Forniamo all'entità T4 un elenco di tabelle da cui generare entità e una sintassi per indicare che l'entità basata su una tabella deve ereditare dall'entità in base a un'altra. Il codice personalizzato va in classi parziali. Quindi la nostra soluzione sembra più simile alla mia opzione 1 di cui sopra.

Inoltre, abbiamo iniziato a generare una fluente configurazione in OnModelCreating nel DbContext, ma ci siamo scambiati per usare gli attributi sulle Entità (dove esistono gli attributi - HasPrecision era uno che dovevamo usare per la fluente configurazione). Abbiamo scoperto che è più conciso e più facile localizzare la configurazione di una proprietà quando è proprio lì a decorare quella proprietà.