NHibernate und Code zuerst

Question

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-Datenbank-Projekt) und dann Mappings und persistente Klassen oder EF-Entitäten mit Designer. Aber jetzt möchte ich Code zuerst mit Fluent NHibernate angehen.

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 in Produktionsdatenbank und so weiter ...

Ich möchte wissen, verwenden Sie wirklich Code zuerst und SchemaExport (SchemaUpdate) in Ihren Anwendungen? Kann sein, dass Sie mir einige Ratschläge geben können ...

Answer 1

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 immer 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 eine Sache: Sie sollten SchemaUpdate manuell von einem Build-Tool ausführen, nicht Ihre App selbst. Es ist nicht sicher, um Ihrer Anwendung die Rechte zu geben, Ihr Datenbankschema zu ändern!

Answer 2

Ja, Sie können diese in realen Anwendungen verwenden; Ich mache.

Natürlich passiert fast die ganze Arbeit in diesem ersten Schritt. Meine Praxis bestand darin, ein separates Projekt zu erstellen, das auf die Zuordnungen 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, aber behalte es als Referenz oder wenn ich jemals von Create-Skripten zu Update-Skripten wechseln muss.

Für die Art, wie NHibernate die Datenbank erstellt, müssen Sie in Ihren Fluent-Zuordnungen etwas mehr Spezifikation angeben, als Sie es sonst tun könnten. Ich möchte gerne null/nicht null, Fremdschlüssel-Constraint-Namen usw. angeben, um maximale Kontrolle über die Art zu haben, wie die Datenbank erstellt wird.

Ich glaube nicht, dass Sie jemals in diesem Szenario automapping verwenden möchten.

Answer 3

Ich verwende SchemaUpdate/SchemaExport für die schnelle Entwicklung meines Modells, aber sie sind kein Ersatz für ein Datenbankmigrationstool. Wie Sie erwähnen, können Daten in vielen Fällen nicht sinnvoll migriert werden. Das Werkzeug hat nicht genügend Kontext. (z. B. Wie können Sie eine FullName-Spalte automatisch in FirstName/LastName migrieren?) Ich habe hier auf eine ähnliche Frage geantwortet, in der ich im Kontext von NHibernate über db-Migrationstools erörtern möchte.

NHibernate, ORM : how is refactoring handled? existing data?

Answer 4

einfach mit jedem erzeugten Codes, ob es sich wie in Ihrer Frage poco Generation von einem Werkzeug oder Datenbank-Generation sein, wird es wahrscheinlich für Sie da 80% der Art und Weise bekommen.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.