Cómo refactorizar código/esquema DB con código EF 4 primero - Migración de datos

Question

¿Cuáles son las mejores prácticas para la refactorización de bases de datos con codefirst EF4?

Me interesa saber cómo las personas cambian las clases y la base de datos cuando la opción RecreateDatabaseIfModelChanges no es factible. La migración de datos tendrá que ocurrir.

Actualmente Microsoft tiene una solución para hacer esto con el modelo de primera:

http://blogs.msdn.com/b/adonet/archive/2010/02/08/entity-designer-database-generation-power-pack.aspx?PageIndex=2#comments

¿Alguien tiene una buena estrategia para el código en primer lugar?

Answer 1

El equipo de EF han estado trabajando en un migraciones característica para EF que debe resolver este problema.

http://blogs.msdn.com/b/efdesign/archive/2010/10/22/code-first-database-evolution-aka-migrations.aspx

de Scott Gu dijo en su reciente gira por Europa que deberían estar liberando esta característica pronto. Estoy conteniendo la respiración.

emocionante versión:

Esto ya se ha lanzado como CTP: http://blogs.msdn.com/b/adonet/archive/2011/07/27/code-first-migrations-august-2011-ctp-released.aspx

Answer 2

Estoy trabajando en el inicializador de contexto de la base de datos que notificará al webmaster si el modelo y el esquema db no están sincronizados y mostrará qué difiere. Esto puede ser útil para desarrolladores que prefieren tener un control completo sobre el modelo de primer código y el esquema de la base de datos. Compruébelo usted mismo:

https://github.com/rialib/efextensions

Answer 3

En mi solicitud CodeFirst, locales construye tener una bandera app.config que no denota estar en producción. Cuando no estoy en producción, destruye por completo y recrea la base de datos. Como el usuario de la base de datos de producción NO tiene permisos para eliminar la base de datos, incluso si mi transformación web.config se pierde de alguna manera (por lo tanto, EF intenta recrear la base de datos) mi base de datos de producción no se eliminará y se lanzará una excepción.

Mi flujo de trabajo es el siguiente:

1. Salida rama de producción de código con la última cambia
2. prueba de humo/regresión rápidamente (esto ya se debe hacer antes de comprobar el código en la rama de producción, pero sólo por si acaso)
3. descargar la última copia de seguridad de mi base de datos de producción e instalarlo en mi servidor local de SQLEXPRESS
4. Run Open DBDiff entre la base de datos de mi código local creado (aunque es el código de producción, ya que es lo recr locales compra la base de datos) contra la copia de seguridad de producción.
5. Revise los scripts generados e intente ejecutarlos contra la copia de seguridad de producción
6. Suponiendo que no se produjeron errores, sobrescriba la base de datos que generó el código con la copia de seguridad de producción y haga pruebas contra los datos de producción para asegurarse de que todos los datos estén intactos;
7. Ejecutar scripts en la base de datos de producción real.

El paso # 2 crea automáticamente una base de datos nueva y limpia basada en el último modelo de datos, así que siempre sé que tengo una base de datos actualizada que no contiene artefactos de esfuerzos de desarrollo que aún no están listos para la producción.