Bester Weg, um Daten im Entitätsgerüst 4.3 inkrementell zu säen

Question

Ich habe Entity Framework 4.3 in einer vorhandenen Datenbank verwendet und habe ein paar Szenarien, für die ich versuche, zu sorgen.

Erstens, wenn ich meine Datenbank lösche, möchte ich, dass ich von Grund auf neu erstellt werden möchte, habe eine CreatedatabaseIfnotexists -Datenbank initialiser erfolgreich verwendet.

Zweitens möchte ich, dass die Datenbank automatisch aktualisiert wird, wenn ich mein Modell und die Datenbank aktualisiere. Ich habe dafür erfolgreich Entity Framework 4.3 -Migrationen verwendet.

Also hier ist meine Frage. Angenommen, ich füge meinem Modell eine neue Tabelle hinzu, die einige Referenzdaten erfordert, was der beste Weg ist, um sicherzustellen, dass diese Daten sowohl erstellt werden, wenn die Datenbank intialer ausgeführt wird als auch wenn die Migration ausgeführt wird. Mein Wunsch ist, dass die Daten erstellt werden, wenn ich die DB von Grund auf neu erstelle und auch wenn die Datenbank als Ergebnis einer Migration aktualisiert wird.

In einigen Beispielen für EF -Migrationen habe ich gesehen, dass Personen die SQL () -Funktion in der UP -Methode der Migration verwenden, um Samendaten zu erstellen, aber wenn möglich würde ich den Kontext lieber verwenden, um die Samendaten zu erstellen (wie Sie in den meisten Datenbank -Initialiser -Beispielen angezeigt werden) Wie es mir seltsam erscheint, würden Sie reine SQL verwenden, wenn die ganze Idee von EF das abstrahiert. Ich habe versucht, den Kontext in der UP -Methode zu verwenden, aber aus irgendeinem Grund glaubte es nicht, dass eine Tabelle, die in der Migration erstellt wurde, existierte, als ich versuchte, die Samendaten direkt unter dem Aufruf hinzuzufügen, um die Tabelle zu erstellen.

Jede Weisheit sehr geschätzt.

Answer 1

Wenn Sie Entitäten zur Saatdaten verwenden möchten, sollten Sie verwenden Seed Methode in Ihrer Migrationskonfiguration. Wenn Sie ein frisches Projekt generieren Enable-Migrations Sie erhalten diese Konfigurationsklasse:

internal sealed class Configuration : DbMigrationsConfiguration<YourContext>
{
    public Configuration()
    {
        AutomaticMigrationsEnabled = false;
    }

    protected override void Seed(CFMigrationsWithNoMagic.BlogContext context)
    {
        //  This method will be called after migrating to the latest version.

        //  You can use the DbSet<T>.AddOrUpdate() helper extension method 
        //  to avoid creating duplicate seed data. E.g.
        //
        //    context.People.AddOrUpdate(
        //      p => p.FullName,
        //      new Person { FullName = "Andrew Peters" },
        //      new Person { FullName = "Brice Lambson" },
        //      new Person { FullName = "Rowan Miller" }
        //    );
        //
    }
}

Die Art und Weise, wie Migrationssamendaten nicht sehr effizient sind, da sie für eine sehr einfache Aussaat verwendet werden sollen. Jedes Update auf eine neue Version wird den gesamten Set durchlaufen und versucht, vorhandene Daten zu aktualisieren oder neue Daten einzufügen. Wenn Sie nicht verwenden AddOrUpdate Erweiterungsmethode Sie müssen manuell sicherstellen, dass Daten nur dann in die Datenbank ausgesät werden, wenn sie noch nicht vorhanden sind.

Wenn Sie eine effiziente Möglichkeit zum Aussaat wünschen, weil Sie viele Daten säen müssen, erhalten Sie ein besseres Ergebnis mit gemeinsamen:

public partial class SomeMigration : DbMigration
{
    public override void Up()
    {
        ...
        Sql("UPDATE ...");
        Sql("INSERT ...");
    }

    public override void Down()
    {
        ...
    }
}

Answer 2

Ich würde nicht empfehlen, die Verwendung zu verwenden Sql() Anruf in Ihrem Up() Methode Weil (IMO) dies wirklich für den tatsächlichen Migrationscode bestimmt ist, für den es keine integrierte Funktion gibt, anstatt Saatgutcode.

Ich denke gerne Samendaten als etwas, das sich in Zukunft ändern könnte (auch wenn mein Schema nicht der Fall ist) bisher.

Betrachten Sie ein Szenario, in dem Sie eine "Typ" -Tabelle haben, die mit 3 Einträgen beginnt, aber später einen vierten hinzuzufügen. Sie sollten keine "Migration" benötigen, um dies anzugehen.

Verwendung Seed() gibt Ihnen auch einen vollständigen Kontext, mit dem Sie arbeiten können, was viel schöner ist als die einfachen SQL -Zeichenfolgen in der Sql() Methode, die Ladislav demonstrierte.

Beachten Sie auch, dass der Vorteil der Verwendung integrierter EF-Methoden sowohl für den Migrationscode als auch für den Saatgutcode darin besteht, dass Ihre Datenbankvorgänge plattformneutral bleiben. Dies bedeutet, dass sich Ihr Schema ändert und Abfragen auf Oracle, Postgre usw. ausgeführt werden können. Wenn Sie den tatsächlichen RAW -SQL schreiben, können Sie sich möglicherweise unnötig einschließen.

Sie sind vielleicht weniger besorgt darüber, da 90% der Menschen, die EF verwenden, immer nur SQL Server treffen, aber ich werfe sie nur raus, um Ihnen eine andere Perspektive auf die Lösung zu geben.