NHibernate, ORM: Wie wird mit dem Refactoring umgegangen? existierende Daten?

Question

Wie wird bei der Verwendung eines ORM (speziell NHibernate) das Refactoring von Daten gehandhabt? Ich meine, wenn sich Datenobjekte so ändern, dass sich das zugrundeliegende relationale DB-Schema ändert, bietet das ORM dann Hilfe bei Schema-Upgrades/Downgrades in der DB? Wie steht es mit der Migration vorhandener Daten in das neue Schema?

Ich bin dabei, eine Entscheidung über die Verwendung eines ORM zu treffen und habe eine sehr begrenzte Exposition. Bitte tragen Sie mit mir, wenn die Fragen naiv sind.

Answer 1

In NHibernate können Sie mit der SchemaUpdate-Klasse zusätzliche Änderungen an Ihrem Schema vornehmen. (Additive Änderungen würden neue Tabellen, neue Spalten usw. enthalten, aber nicht gelöscht.) SchemaUpdate ist für Entwicklungszwecke vorgesehen und nicht für die Produktion vorgesehen. Ich würde dringend empfehlen, ein SQL-Migrationstool wie Tarantino, dbdeploy.net, RikMigrations oder ähnliches auszuprobieren.

Migrationstools gibt es in zwei Varianten - SQL-Skript-basiert (Tarantino und dbdeploy.net) und code-basiert (RikMigrations und Rails-Stil-Migrationen). Mit einem code-basierten Migrationstool schreiben Sie Ihre Migrationen mit Code, der in C#, VB, Ruby, ... geschrieben wurde. SQL-Skript-basierte Tools nehmen eine geordnete Menge von SQL-Skripten entgegen. In beiden Fällen führt das Migrationstool Migrationen für Ihre Datenbank aus, die zuvor noch nicht ausgeführt wurden. (In der Regel eine Migrationen Tabelle sind die Skripte, die ausgeführt wurden, und ermöglicht es dem Werkzeug, um herauszufinden, was immer noch ausgeführt werden müssen.) Die SQL-Skripte generiert werden über:

// SchemaUpdate.Execute(bool script, bool doUpdate) 
new SchemaUpdate(cfg).Execute(true, false); 

und dann nach Geschmack bearbeitet. Oder Sie könnten ein neues Schema mit NHibernate's SchemaExport erstellen und ein Schema-Diff-Tool wie Microsoft Visual Studio für Datenbankprofis Ultimate jetzt mit Extra Mayo Edition (alias DataDude) oder RedGate SQL Compare verwenden. Sie müssten Transformationsskripte von Hand schreiben, da es für das SQL-Migrationstool normalerweise keine Möglichkeit gibt, zu wissen, dass die Foo char (1) -Spalte, die mit T/F gefüllt ist, in diese Bar-Bit-Spalte umgewandelt werden sollte.

Persönlich bevorzuge ich die SQL-Skript-basierten Migrationstools, da ich die Schema-Diffs mit einem Werkzeug generieren und dann nach Geschmack bearbeiten kann, anstatt die gesamte Migration mit C# oder einer ähnlichen Sprache von Hand durchführen zu müssen.