[gelöst] MVC: Code First, aber wie krieg ich das ganze in das Echtsystem?

Hi,

ich baue meine MVC-Anwendung mit dem EF Code-First-Pinzip. Wenn ich Änderungen an meinen Modellen mache, lege ich per Packet-Manager-Konsole per Add-Migration und Update-Database die Änderungen auf meiner Entwicklungsdatenbank ab.

Aber wie muss ich vorgehen, wenn ich die Migration am Ende auch auf meinem Echtsystem machen möchte? Bisher bleibt mit nichts anderes übrig, als die gesamte Datenbank zu killen und dann neu generieren zu lassen. Kann ich das Add-Migration auch irgendwie auf meinem Server machen?

Gruß

dat Levion

Hallo dat Levion,

ich habe mich zwar selbst damit noch nicht befasst, aber es gibt hier ein paar gute Tutorials von Microsoft zu diesem Thema. Ich kann auch den ADO.NET Blog hierzu empfehlen.

Code First Migrations

Gruß,
Ronny

Hallo Levion,

mit "update-database -verbose" wird der endgültige SQL-Befehl der an die Datenbank gesendet wird in der Packagemanager Console ausgegeben.

Diesen kannst du kopieren und am Produktiv-System ausführen.

Ich mach das so, habe aber nicht nur eine sondern mehrere Produktiv-Datenbanken die ich von der Struktur her "synch" halten muss.

lg

Ne Webanwendung ist vom Prinzip her nicht anders, als ne Desktopanwendung - jedenfalls abstrakt gedacht. Da wird ja auch nicht von Hand nen DB-Update gemacht. Das passiert in der Regel automatisch durch die Anwendung.

Du hast auch bei MVC einen Part, der nur beim Start geladen wird. Dieses ist eben Application_Start in der Global.cs bzw. App_Start bei MVC4. Darin kann ja die Prüfung und Migration der Datenbank stattfinden.

Um Inkompatibilitäten zu entdecken gibts verschiedene Wege.
CustomInitializer, FindCompatibilityIssues()

Über den DBMigrator gibts dann auch noch den Aufruf GetPendingMigrations()

Warum nicht einfach in der web.config bzw. app.config den ConnectionString für die produktiv DB angeben und Update-Database ausführen?

Den gesamten ConnectionString in die config-Datei zu pflegen halte ich als Notlösung.
Vieles bei MVC bzw. generell neuen .NET Technologien ist in den Beispielen so angegeben, dass sie leicht umzusetzen sind.

Wenn es aber um komplexere Dinge geht, dann sollte man sowas tunlichst vermeiden, da es unflexibel und wartungsaufwändig wird.
Beispiel bei MVC: alle Views arbeiten nicht mit ViewModels oder mit SubmitModels. Alles sehr sehr einfach gehalten.
Beispiel EF: seltenst wird ein Repository verwendet.

Ein Beispiel für den Connectionstring + Lösung sieht man in Entity Framework (C#) mit mehreren DB Enities

Ich hab' in meiner Global.asax.cs das hier eingefügt.

Database.SetInitializer(new MigrateDatabaseToLatestVersion<MainDbContext, Configuration>());

Das funktioniert super und ist genau was ich wollte. Meine Anwendung kümmert sich ums Update und ich kümmer mich ums Programmieren 😃

Danke, euch!

Den gesamten ConnectionString in die config-Datei zu pflegen halte ich als Notlösung.

Was ist wenn die Datenbank auf einen neuen Server zieht? In deinem Beispiel müsstest du die Anwendung neu kompillieren.

Mittlerweile unterstützt VS auch mehrere *.config-Versionen (Debug, Release).

Halte es für zielführender und sinnvoller solche Informationen in config-Dateien zu pflegen und nicht im Code.

Also, dass die Daten an sich aus der Config leben sollte klar sein 🤔 und dann ist auch kein neues Kompilieren notwendig. Es ist schließlich ein Beispiel und meine Konfig-Struktur kann ich schlecht als Beispiel verwenden, da sie nichts mit vergleichbaren zutun hat.
Aber der gesamte Connectionstring gehört einfach nicht in die web.config...

Wenn man ein Mandanten-System hat funktioniert zB der ConnectionString in der config überhaupt nicht (außer man pflegt n Einträge in der Config, was quatsch ist).