2012-05-30 17 views
19

estoy aprendiendo EF4.3 migración, y he leído estos dos artículos de ado.net blog del equipo:migración automática vs migración del código de base

http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx

http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx

pero después de leer estos dos artículos, todavía no aclaro cuál es la diferencia entre ellos y cuándo utilizar la migración basada en código, cuándo usar la migración automática. ¿Alguien puede guiarme?

Gracias!

+3

Odio cómo la EM simplemente se apropia del vocabulario. Algunos de nosotros pensamos que "migración de código" significa "convertir código de un idioma/plataforma a otro" y que "migración automática" significa "hacer migración de código automáticamente". –

+0

@IraBaxter me recuerda el tema de contextos delimitados en DDD. http://martinfowler.com/bliki/BoundedContext.html –

+0

Parece que los enlaces ya no funcionan, ¿hay algún artículo actualizado sobre esto? –

Respuesta

22

Esos artículos son muy claros, por lo que si no comprende la diferencia significa que no se concentró mientras leía el texto y que probablemente tampoco siguió el texto al codificar los ejemplos.

La migración automática es solo una herramienta mágica. Ejecuta su aplicación y siempre obtendrá su base de datos en la última versión porque EF realizará la migración implícita cada vez que sea necesario; en la versión más pura, no necesita hacer nada más que habilitar migraciones automáticas.

Las migraciones automáticas a veces no son suficientes. Necesita agregar alguna personalización al código de migración o ejecutar algunos comandos SQL adicionales, por ejemplo, para transformar datos. En tal caso, agrega una migración explícita basada en código llamando al comando Add-Migration. La migración explícita muestra todos los códigos de migración que se ejecutarán durante la migración (no hay magia adicional).

Si desactivas las migraciones automáticas, siempre debes definir una migración explícita para definir el proceso de actualización de la base de datos en pasos explícitos bien definidos. Esto es especialmente útil para escenarios en los que necesita usar tanto la actualización como la degradación a una versión específica.

+1

Cuando @Ladislav Mrnka dice "Las migraciones automáticas a veces no son suficientes" ¿Puede indicarme una lista de escenarios que no maneja Migraciones automáticas? He visto esta declaración muchas veces en Internet, incluso en la documentación oficial [EF 5] (http://msdn.microsoft.com/en-US/data/jj554735) pero nunca se da una lista de limitaciones. –

+2

@Steven: No encontrará una lista de limitaciones en ningún lado. A veces, por ejemplo, usted realiza cambios que no solo necesitarán cambiar la estructura de la tabla, sino también transformar los datos, lo que requiere la migración de código donde maneja los datos manualmente. Algunas veces desea agregar algunas características SQL adicionales: índices, restricciones atc. De nuevo, eso solo es posible con la migración de código. Casi siempre que necesite utilizar los métodos 'Sql' o' CreateIndex' o 'DropIndex' requiere una migración de código. –

+0

Gracias por proporcionar algunas pautas. –

-2

Puede encontrar más información sobre MSDN. No recomiendan mezclar migraciones automáticas y basadas en códigos en escenarios de desarrollo de equipos. Pero no entiendo claramente qué problemas puede crear.