NHibernate und Code zuerst

8

Verwenden Sie SchemaExport und SchemaUpdate in realen Anwendungen? Sie erstellen zunächst ein Modell und dann ein Schema? Funktioniert es? Oder Sie verwenden es nur für Tests ...

Normalerweise erstelle ich db (mit Visual Studio-Datenbankprojekt) und dann Mappings und persistente Klassen oder EF-Entities mit Hilfe von Designer. Aber jetzt möchte ich Code zuerst mit Fluent NHibernate versuchen.

Ich habe SchemaExport und SchemaUpdate recherchiert und einige Probleme gefunden. Zum Beispiel löscht update keine db-Objekte, erstellt keine Null-Spalten wie Nullable, wenn die Tabelle existiert, erzeugt keinen Primärschlüssel für Viele-zu-Viele-Tabellen und so weiter. Es bedeutet, dass ich db sehr oft neu erstellen muss. Aber was ist mit Daten? Und, wie man Änderungen an der Produktionsdatenbank usw. ausgibt ...

Ich möchte wissen, verwenden Sie wirklich Code und SchemaExport (SchemaUpdate) in Ihren Anwendungen? Vielleicht kannst du mir Ratschläge geben ...

    
Andy 18.11.2010, 15:49
quelle

4 Antworten

8

Ich verwende SchemaUpdate in der Produktion. Es ist sicher, weil es keine destruktiven Operationen wie das Löschen von Spalten durchführt. Es ist jedoch keine umfassende Lösung für die Aktualisierung Ihrer Datenbank. Wenn Sie es verwenden, müssen Sie es noch mit einem Skript ergänzen, um Ihr Schema zu aktualisieren, zB Löschen (wie Sie es nennen), Indexieren, Ändern des Spaltentyps, Hinzufügen von Tabellendaten usw. Aber SchemaUpdate deckt den 90% -Fall für mich ab.

Der einzige Nachteil, den ich entdeckt habe, ist, dass es im Laufe der Zeit gelegentlich doppelte Fremdschlüsseleinschränkungen zu meiner Tabelle hinzufügt.

Noch etwas: Sie sollten SchemaUpdate manuell von einem Build-Tool ausführen, nicht von Ihrer App selbst. Es ist nicht sicher , Ihrer Anwendung die Rechte zur Änderung Ihres Datenbankschemas zu geben!

    
Gabe Moothart 18.11.2010, 16:01
quelle
4

Ich verwende SchemaUpdate / SchemaExport für die schnelle Entwicklung meines Modells, aber sie ersetzen kein Datenbankmigrationstool. Wie Sie erwähnen, können Daten in vielen Fällen nicht sinnvoll migriert werden. Das Werkzeug hat nicht genügend Kontext. (Wie können Sie beispielsweise eine FullName-Spalte automatisch in FirstName / LastName migrieren?) Ich habe hier eine ähnliche Frage beantwortet, in der ich die DB-Migrationstools im Kontext von NHibernate behandle.

NHibernate, ORM: Wie wird mit Refactoring umgegangen? vorhandene Daten?

    
James Kovacs 18.11.2010 16:13
quelle
2

Ja, Sie können diese in realen Anwendungen verwenden; Das tue ich.

Natürlich passiert fast die ganze Arbeit in diesem ersten Schritt. Meine Praxis bestand darin, ein separates Projekt zu erstellen, das auf die Mappings in meiner Hauptprojektgruppe verweist und die Datenbankerstellung und gegebenenfalls den anfänglichen Datenimport abwickelt.

Sobald das Projekt in Produktion ist, entlade ich normalerweise dieses Projekt aus der Lösung, behalte es jedoch als Referenz oder wenn ich jemals von Create-Skripten zu Update-Skripten wechseln muss.

Was die Art und Weise betrifft, wie NHibernate die Datenbank erstellt, müssen Sie in Ihren Fluent-Zuordnungen etwas mehr Angaben machen als sonst. Ich möchte gerne Null / Nicht-Null, Fremdschlüssel-Constraint-Namen usw. angeben, um maximale Kontrolle darüber zu haben, wie die Datenbank erstellt wird.

Ich glaube nicht, dass Sie in diesem Szenario jemals Auto-Mapping verwenden möchten.

    
Jay 18.11.2010 16:07
quelle
1

Nur mit irgendeinem generierenden Code, ob es poco Erzeugung von einer Werkzeug- oder Datenbankerzeugung wie in Ihrer Frage ist, wird es Ihnen wahrscheinlich 80% des Weges dorthin bringen. Von dort wäre es ratsam, die anderen 20% zu optimieren, um Ihre Indizes und andere Leistungsoptimierungen hinzuzufügen, um es genau richtig zu machen.

    
Chris Conway 18.11.2010 16:20
quelle

Tags und Links