Datenbankmigrationen für Entity Framework 4

Question

Ich habe mit Entity Framework 4 gespielt und den modellgesteuerten Ansatz verwendet, um das Datenbankskript aus meinen Entitäten zu generieren.Das ist großartig, aber ich bin mir nicht sicher, wie das funktioniert, wenn es um die Versionierung der Datenbank geht.Ich vermute, wenn ich ein aktives Migrationsframework für Datensatztypen verwenden wollte, müsste ich umgekehrt vorgehen und meine Entitäten aus meiner Datenbank generieren?Gibt es eine Möglichkeit, den modellgesteuerten Ansatz zu verwenden und die Datenbank ordnungsgemäß zu versionieren?

Answer 1

Dies wird in Kürze als NuGet Paket namens EntityFramework.Migrations

Es wurde eine Demo von Scott Hanselman auf der TechEd 2011 (online verfügbar unter http ausgeführt: //channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV349 ). Der entsprechende Abschnitt ist 45 Minuten in.

Kurz gesagt, sobald das Paket installiert ist, werden Sie die folgenden in das Package Manager-Konsole geben Sie eine Datenbank Change Script zu generieren:

migrate -script

UPDATE (13-Nov-2011)

Die Alpha 3 Build dieses Paket ist jetzt auf NuGet zur Verfügung. Anstatt Verwendung des Cmdlets migrate -script oben erwähnt, verwendet er das Cmdlet Add-Migration <migrationname>. A EntityFramework NuGet verpacken , ab Version 4.3. Ein aktualisiert Freilos mit EF 4.3 kann auf dem ADO.NET Team Blog.

Answer 2

Sie können versuchen, Wizardby : Dies ist ein Werkzeug für die Datenbankmigrationen zu verwalten. Es integriert nicht mit EF (da es fast unmöglich ist, mit ihm in dieser Hinsicht zu integrieren), aber macht den Job.

Answer 3

ScottGu erwähnt etwas dazu in einem Blog-Eintrag:

Wir werden in Zukunft auch eine „Migrations“-Funktion mit EF unterstützen, die es Ihnen ermöglicht, Datenbankschemamigrationen programmgesteuert zu automatisieren/zu skripten.

[BEARBEITEN]

Ich denke, er könnte sich auf das beziehen Power Pack zur Entity Designer-Datenbankgenerierung, wie von Morteza Manavi in ​​beantwortet noch eine SO-Antwort.

Answer 4

Nun, wenn Sie an der Arbeit wie Active wollen, dann müssen Sie wie Active an der Arbeit. :)

Wenn Sie jedoch modell zuerst verwenden möchten, aber noch Migrationen verwenden, wird dies möglich sein, werden aber zusätzliche Arbeit in Ihrem Namen benötigen. Model erstes wird ein Datenbank Change Script generieren. Sie werden die entsprechenden Teile in Migrationen sowie manuell zu schreiben Undo-Skripte entpacken. Obwohl dies einige manuelle Arbeit beinhaltet, ist es mir nicht so furchtbar schwer treffen.

Answer 5

Ich arbeite an einer Alternative zu EF.Migrations Bibliothek - EntityFramework.SchemaCompare . Es ermöglicht die physikalisch ein DB-Schema mit einem Einheiten-Modell vergleichen darstellt Datenbankkontext (EF.Migrations es nicht tun). Dies kann entweder während der Datenbank-Initialisierung oder manuell auf Anfrage abgefeuert werden. Betrachten Sie das folgende Beispiel

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

Es wird eine Ausnahme während Datenbankinitialisierung beschreibt die Unterschiede zwischen db-Schema und Modell werfen, wenn Kompatibilitätsprobleme zu finden sind. Alternativ können Sie diese Unterschiede jederzeit in Ihrem Code auf diese Weise

finden

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

mit dann diese Unterschiede / Kompatibilitätsprobleme auf den Händen können Sie entweder die Db-Schema aktualisieren oder das Modell.

Dieser Ansatz ist besonders nützlich, wenn Sie die vollständige Kontrolle über das Datenbankschema und Design-Modell benötigen und / oder Arbeiten in einem Team, in dem mehrere Teammitglieder auf dem gleichen DB-Schema und Modell arbeiten. Es kann auch zusätzlich zu EF.Migrations verwendet werden.

gabeln ich bei GitHub: https://github.com/kriasoft/data