Domanda

Ho giocato con Entity Framework 4, utilizzando l'approccio basato sul modello per generare lo script del database dalle mie entità.È fantastico ma non sono sicuro di come funzioni quando si tratta di controllare le versioni del database.Immagino che se volessi utilizzare un framework di migrazione del tipo di record attivo dovrei lavorare al contrario e generare le mie entità dal mio database?Esiste un modo per utilizzare l'approccio basato sul modello e versionizzare correttamente il database?

È stato utile?

Soluzione

Questo sarà presto disponibile come pacchetto NuGet chiamati EntityFramework.Migrations

Una demo è stata effettuata da Scott Hanselman al TechEd 2011 (disponibile online all'indirizzo http: //channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV349 ). La sezione pertinente è di 45 minuti in.

In breve, una volta installato il pacchetto, si entra quanto segue nella console di Package Manager per generare uno script modifica del database:

migrate -script

UPDATE (13-Nov-2011)

L'alfa 3 generazione di questo pacchetto è ora disponibile su NuGet. Invece di usare il migrate -script cmdlet menzionato sopra, viene utilizzato il Add-Migration <migrationname> cmdlet. Un walk-through del suo utilizzo si possono trovare sul blog del team di ADO.NET.

UPDATE (14-Feb-2012)

Questa funzionalità è ora disponibile come parte del EntityFramework NuGet pacchetto , a partire dalla versione 4.3. Un aggiornato walk-through utilizzando EF 4.3 sono disponibili sul blog del team di ADO.NET.

Altri suggerimenti

Si può provare a Wizardby : questo è uno strumento per la gestione delle migrazioni di database. Essa non si integra con EF (dal momento che è quasi impossibile integrarsi con essa in questo senso), ma non il lavoro.

ScottGu menziona qualcosa al riguardo in a voce del blog:

In futuro supporteremo anche una funzionalità di "migrazione" con EF che consentirà di automatizzare/scriptare le migrazioni dello schema del database a livello di codice.

[MODIFICARE]

Penso che potrebbe riferirsi a Power pack per la generazione di database di Entity Designer, come ha risposto Morteza Manavi in un'altra risposta SO.

Bene, se si desidera lavorare come ActiveRecord, allora avete bisogno di un'opera come ActiveRecord. :)

Tuttavia, se si desidera utilizzare il modello-first, ma usa ancora le migrazioni, questo sarà possibile, ma richiederà lavoro extra a vostro nome. Model-First genera uno script di modifica del database. Si dovrà estrarre le parti rilevanti nelle migrazioni, così come la scrittura manuale undo script. Anche se questo comporta qualche lavoro manuale, non mi sembrano terribilmente difficile.

Sto lavorando su un'alternativa alla libreria EF.Migrations - EntityFramework.SchemaCompare . Permette di confrontare fisicamente uno schema db con un modello di entità che rappresenta il contesto di database (EF.Migrations non lo fanno). Questo può essere licenziato sia durante l'inizializzazione del database o manualmente su richiesta. Si consideri il seguente esempio

#if DEBUG
Database.SetInitializer(new CheckCompatibilityWithModel<DatabaseContext>());
#endif

Sarà un'eccezione durante l'inizializzazione del database che descrive le differenze tra lo schema db e il modello se si trovano problemi di incompatibilità. In alternativa si possono trovare queste differenze in qualsiasi momento nel codice in questo modo

using (var ctx = new DatabaseContext())
{
    var issues = ctx.Database.FindCompatibilityIssues();
}

Poi avere quei problemi di incompatibilità / Differenze sulle mani è possibile aggiornare sia lo schema db o dal modello.

Questo approccio è particolarmente utile quando è necessario il controllo completo sul disegno schema del database e modello e / o di lavoro in una squadra in cui più membri del team stanno lavorando sullo stesso schema db e modello. Può essere utilizzato anche in aggiunta a EF.Migrations.

mi forchetta GitHub: https://github.com/kriasoft/data

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top