| 

.NET C# Java Javascript Exception

10
Hallo,

ich habe angefangen das Entity Framework etwas intensiver zu nutzen, und bin damit vorerst auch recht zufrieden. Ich handhabe es im Moment nach dem Code First System, also zuerst das Model erstellen und dann die Datenbank updaten. Das Ganze hat aber einen Haken der mich immer mehr stört.

Anhand des Models wird das SQL-Script generiert (vorhandene EF Funktionalität), welches die Datenbank aktualisiert. "Aktualisiert" ist aber leider der falsche Begriff, denn es löscht alle Inhalte der Datenbank und legt diese neu an. Gibt es eine Möglichkeit das Update der Datenbank vorzunehmen, ohne dass ich dann alle darin vorhandenen Daten verliere?

Vielen Dank.
News:
16.02.2012
SensenMannLE 1,2k 1 9
2 Antworten
3
Hallo,

deinem Text kann ich entnehmen, dass du einen DatabaseInitializer verwendest (Eingetragen in der global.asax) dieser legt fest, wie das Datenbank Model aktualisiert wird. Hier hat man momentan die Wahl zwischen 3 Verschiedenen:

  • DropCreateDatabaseIfModelChanges -> Bei Modeländerungen wird die Datenbank verworfen und neu generiert (Wie der Name es auch sagt)
  • CreateDatabaseIfNotExists -> generiert NUR DANN eine neue Datenbank wenn noch keine existiert, daher müssen alle weiteren Änderungen manuell nachgepflegt werden.
  • DropCreateDatabaseAlways -> gibt bei jeder Initialisierung eine frisch generierte Datenbank


Für die Entwicklungsumgebung macht natürlich DropCreateDatabaseIfModelChanges sinn, da man dann immer auf dem aktuellen Modelstate arbeitet, in einer Produktiven Umgebung ist das natürlich mist, da bei einer Änderung alle Daten weg sind!

Deswegen gibt es das Entity Framework Code First SqlMigrations
http://www.hanselman.com/blog/EntityFrameworkCodeFirstMigrationsAlphaNuGetPackageOfTheWeek10.aspx

Dieses "Tool" analysiert für dich die Datenbank bei Modeländerungen und erzeugt automatisch SQL-Skripte die dann auf der Datenbank ausgeführt werden.
So werden Datenbanken erweitert und nicht neu erzeugt. Dabei werden die neuen Spalten mit null gefüllt, da es dafür noch keine Daten gibt.

So kann man sehr bequem arbeiten und verliert dabei nicht die schönen vorteile von Code First.

Natürlich gibt es auch hier noch ein paar Fallen auf die man achten muss, aber das wird ja auch zunehmend weiterentwickelt und funktioniert dafür schon ganz gut. Einen Versuch ist es definitiv wert!

Innerhalb des DatabaseInitializers kannst du des Weiteren auch deine ganzen Mappings verwalten und manuell durchführen, dafür muss man nicht unbedingt auf ein anderes Framework ausweichen. Mehr dazu hier:
http://weblogs.asp.net/scottgu/archive/2010/07/23/entity-framework-4-code-first-custom-database-schema-mapping.aspx

Hoffe das hilft dir weiter.
20.02.2012
bigbasti 131 2
Danke für die Antwort, das sieht sehr vielversprechend aus. Ich werde es heute Abend testen, und falls das Ergebnis im Ansatz dem entspricht, was ich erwarte, dann gibt's auch den "Antwort-Haken".
SensenMannLE 21.02.2012
1
Jo, das passt. Noch nicht perfekt, aber eine kleine Erleichterung.
SensenMannLE 21.02.2012
1
ich persönlich halte nicht viel von dem Code First Ansatz. Datenbank ist Datenbank und Anwendung ist Anwendung. Hinter beiden stehen ganz unterschiedliche Paradigmen. Das Mapping zwischen der Datenbank und der Anwendung führe ich lieber selbst durch. Damit habe ich die beste Kontrolle sowohl was das Datenbank-Design als auch was das Anwendungsdesign angeht.

Aus diesem Grund verwende ich meist den Powerdesigner, um die Datenbank zu modellieren. Das Tool generiert auch Änderungsskripte, bei denen die Daten erhalten bleiben. Dazu analysiert es die Abhängigkeiten der Tabellen untereinander und erstellt, wenn notwendig, temporäre Tabellen zum Zwischenspeichern von Daten. Dies ist notwendig, weil bestehende Tabellen nicht beliebig geändert werden können. Solange es nur darum geht, Indizes oder neue Spalten hinzuzufügen, ist das ganze kein Problem. Wenn aber z.B. Spalten entfernt werden, die von anderen Tabellen referenziert werden, kann man die Änderung nicht so einfach durchführen. Ich denke, dass die Entwickler des EF aus diesem Grund einfach alle Datenbankinhalte löscht.

Selbst der Powerdesigner als spezialisiertes Datenbankmodeling-Tool ist nicht in allen Fällen in der Lage korrekte Änderungsskripte zu erstellen. Nach einigen bösen Erfahrungen habe ich mir angewöhnt, die generierten Skripte zu kontrollieren, bevor ich sie ausführe.

Lange Rede, Kurzer Sinn: Aus meiner Sicht wirst du um ein wenig Handarbeit nicht herumkommen ;-))

Gruß
Klaus
17.02.2012
luedi 1,7k 1 9
1
Ja, das so strikt getrennt zu sehen hat sicher seine Vorteile, aber auch seine Nachteile. Auf den ganzen "Zuordnungskram" habe ich nämlich eigentlich keinen Bock ;), wenn es Funktionalität gibt, die mir dies liefert. Ein Ansatz ist natürlich die Datenbank direkt zu ändern, und dann das Modell aus der Datenbank zu aktualisieren. Trotzdem stellt sich mir weiterhin die Frage, ob das EF Möglichkeiten bietet, die Visual Studio an anderer Stelle auch hat. Ich verweise hier nur auf den "Datenbank Schemenvergleich", der auch ordentlich Updated und nicht löscht.
SensenMannLE 17.02.2012
welche Version des Entity-Framework setzt du den ein? Ich habe mir die Walkthroughs zum Thema Migrations im EF 4.3 (zu beziehen über NuGet) angesehen. Aus der Beschreibung wird zwar nicht klar, wie die Änderungen intern durchgeführt werden, aber man kann zumindest ein SQL-Skript generieren, welches man anpassen kann.
luedi 18.02.2012
Seit heute verwende ich die 4.3er Version. Ich habe mir auch die Beschreibungen zum Thema Migration durchgelesen. Verstanden habe ich das allerdings nicht wirklich ;) Ich bin also mittlerweile dazu übergegangen tatsächlich das SQL-Script so anzupassen, dass nur die neuen Sachen automatisch bearbeitet werden. Änderungen an "Bestandstabellen" mache ich dann manuell.
SensenMannLE 18.02.2012

Stelle deine .net-Frage jetzt!