NHibernate y el código primero

Question

¿Utiliza SchemaExport y SchemaUpdate en aplicaciones reales? Inicialmente, ¿usted crea un modelo y luego genera un esquema? ¿Funciona? O bien, lo usa solo para las pruebas ...

Normalmente, creo db (utilizando el proyecto de base de datos visual studio) y luego mapeos y clases persistentes o entidades EF utilizando el diseñador. Pero ahora, quiero probar el primer acercamiento de código con Fluirte NHibernate.

Investigué SchemaExport y SchemaUpdate y encontré algunos problemas. Por ejemplo, la actualización no elimina los objetos db, no crea columnas nulas como anulables si la tabla existe, no genera claves primarias en tablas de muchos a muchos y así sucesivamente. Significa que tengo que recrear DB muy a menudo. Pero, ¿qué pasa con los datos? Y, ¿cómo implementar cambios en producción db y así sucesivamente ...

Quiero saber, ¿realmente usan código primero y SchemaExport (SchemaUpdate) en sus aplicaciones? Puede ser que pueda darme algunos consejos ...

Answer 1

Utilizo SchemaUpdate en producción. Es seguro precisamente porque nunca realiza operaciones destructivas como eliminar columnas. Sin embargo, no es una solución integral para actualizar su base de datos. Si lo usa, deberá completarlo con una secuencia de comandos para actualizar su esquema y hacer cosas como eliminar (como usted menciona), índices, cambiar el tipo de columna, agregar datos de tabla, etc. Pero SchemaUpdate cubre el 90% de los casos.

El único inconveniente que he descubierto es que con el tiempo parece añadir ocasionalmente restricciones duplicadas de clave foránea a mi tabla.

Una cosa más: debe ejecutar SchemaUpdate manualmente desde una herramienta de compilación, no desde su aplicación. ¡Es no seguro para otorgar a su aplicación los derechos para modificar su esquema db!

Answer 2

Sí, puede usarlos en aplicaciones reales; Hago.

Por supuesto, casi todo el trabajo ocurre en ese primer intento. Mi práctica ha sido crear un proyecto separado que haga referencia a las asignaciones en mi ensamblaje de proyecto principal y maneje la creación de la base de datos y la importación de datos inicial, si corresponde.

Una vez que el proyecto está en producción, normalmente descargo ese proyecto de la solución, pero lo mantengo como referencia o si alguna vez necesito cambiar de crear scripts para actualizar los scripts.

En cuanto a la forma en que NHibernate crea la base de datos, debe hacer un poco más de especificación en sus asignaciones Fluent de lo que podría haberlo hecho. Me gusta especificar null/not null, nombres de restricción de clave externa, etc. para tener el máximo control sobre la forma en que se crea la base de datos.

No creo que alguna vez quiera usar la automatización en este escenario.

Answer 3

Uso SchemaUpdate/SchemaExport para una rápida evolución de mi modelo, pero no reemplazan a una herramienta de migración de base de datos. Como mencionas, los datos no se pueden migrar de manera sensata en muchos casos. La herramienta no tiene suficiente contexto. (Por ejemplo, ¿cómo se puede migrar automáticamente una columna FullName a FirstName/LastName?) Respondí una pregunta similar aquí donde analizo las herramientas de migración de db en el contexto de NHibernate.

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

Answer 4

Sólo con cualquier código de generación ya sea la generación de poco a partir de una herramienta o la generación de base de datos como en su pregunta, es probable que obtener el 80% del camino.A partir de ahí, sería prudente ajustar el otro 20% para agregar sus índices y cualquier otro ajuste de rendimiento para hacerlo bien.