Tratando con las actualizaciones de esquema en nHibernate/Fluido nHibernate después de la implementación

Question

Al escribir una aplicación que se ejecuta en Fluent Nhibernate/Nhibernate, algo me tiene un poco preocupado. Supongo que esto sería cierto para cualquier ORM (e incluso sin usar un ORM), pero ¿cuál es el ... Supongo que la palabra es "campo de estudio" que se relaciona con las mejores prácticas y métodos para actualizar una base de datos después de la implementación?

En nHibernate, establezco una SessionFactory y tengo una ejecución inicial donde escribe la base de datos basándose en las asignaciones. Está bien y bueno, incluso puedo escribir la base de datos de forma manual. ¿Pero qué pasa cuando mi cliente regresa y quiere que se agregue algo nuevo? ¿Puedo agregar a la base de datos sin perder mis datos? Soy completamente nuevo en todo esto y me ha estado preocupando desde el comienzo de este proyecto, y realmente no sé qué dirección tomar para asegurarme de poder administrar el programa después de su implementación.

He visto otras preguntas sobre el desbordamiento de pila que pude encontrar con respecto a este tema, una de las cuales ni siquiera tenía una respuesta aceptada (aunque la pregunta en sí era bastante vaga), pero descubrí la herramienta http://www.red-gate.com/products/sql-development/sql-compare/ del pregunta Tool to upgrade SQL Express database after deployment aunque me pregunto qué tan buena es una "estrategia".

Answer 1

Hay un par de opciones, utilice the AutoMapping feature in Fluent NHibernate para minimizar el código de mapeo que escribes Si los cambios en su esquema cumplen con las convenciones de AutoMap, entonces solo necesita trabajar con los cambios de objeto de dominio correspondientes.

Otra opción menos óptima es tomar una primera base de datos y tener algo like MyGeneration generar automáticamente las clases de dominio y los archivos de mapeo NHibernate del esquema. Esto funciona si tiene un control completo del esquema de la base de datos y se puede implementar un buen diseño de modelo de dominio (ambas condiciones que rara vez ocurren ...)

En cualquiera de los enfoques, these tools can help maneja las secuencias de comandos de base de datos necesarias para "migrar" el esquema cambia a una nueva versión

Answer 2

Desde mi experiencia, después de la implementación debe mantener manualmente actualizada su estructura de db.
eso significa que cada vez que agrega/cambia su estructura de db, lo hace usando un script con comandos DDL.
cuando esté listo para implementar, simplemente ejecute esos scripts DDL contra su producción db.
por ejemplo, si se agrega una columna de 'bar' a su mesa 'foo', la secuencia de comandos sería algo así como (pseudo-código):

ALTER TABLE foo ADD COLUMN 'bar' int(32) not null default(0);