Migración de EF6 a EF Core: la base de datos como origen de confianza
Si usa la base de datos como origen de confianza, la actualización implicará principalmente abordar los cambios en la forma de las entidades generadas. Los pasos para migrar son los siguientes:
- Elija un momento dado para modelar la base de datos.
- Asegúrese de que los proyectos de EF6 están actualizados y sincronizados con la base de datos.
- Cree el proyecto de EF Core.
- Use las herramientas de scaffolding para realizar ingeniería inversa en la base de datos y obtener su código.
- Valide que las clases generadas por EF Core sean compatibles con el código.
- Para las excepciones, modifique las clases generadas y actualice la configuración del modelo, o bien adapte el código al modelo.
Tenga en cuenta que, aunque EF Core actualmente aplica scaffolding a todo lo necesario para generar correctamente una copia de la base de datos, gran parte del código no es necesario para el enfoque Database First. Se realiza un seguimiento de una corrección para esto en el problema n.º 10890. Entre las cosas que se pueden omitir de forma segura como no necesarias se incluyen las secuencias, los nombres de restricción, los índices no únicos y los filtros de índice.
Control de los cambios del esquema
Cuando la base de datos es el origen de confianza, EF Core extrae información del esquema de la base de datos en lugar de insertarla mediante migraciones. El flujo de trabajo típico consiste en volver a ejecutar el paso de ingeniería inversa cada vez que cambia el esquema de la base de datos. Resulta útil usar un conjunto de pruebas completo para este enfoque, ya que puede automatizar el proceso de scaffolding y comprobar los cambios mediante la ejecución de pruebas.
Sugerencias para controlar las diferencias en los modelos
Es posible que quiera que el modelo de dominio de C# tenga una forma diferente a la del modelo generado mediante la utilización de técnicas de ingeniería inversa por distintas razones. En muchos casos, esto significa actualizar manualmente el código que se genera automáticamente después de cada cambio en el esquema. Una manera de evitar el esfuerzo adicional necesario cuando se vuelve a generar el código es usar clases parciales para DbContext y las entidades relacionadas. A continuación, puede mantener el código relacionado con la lógica de negocios y las propiedades del que no se hace un seguimiento en la base de datos en un conjunto independiente de archivos de clase que no se sobrescribirán.
Si su modelo es significativamente diferente del generado, pero no cambia con frecuencia, considere el uso del patrón de repositorio como un adaptador. El repositorio puede consumir las clases generadas por EF Core y publicar las clases personalizadas que use. Esto puede reducir el impacto de los cambios al aislarlos en el código del repositorio, en lugar de tener que realizar una refactorización en toda la aplicación cada vez que cambia el esquema.
Es posible que quiera plantearse usar un flujo de trabajo alternativo y seguir pasos similares al enfoque híbrido. En lugar de generar un nuevo conjunto de clases cada vez, se indican tablas específicas para generar solo nuevas clases. Las clases existentes se mantienen "tal como están" y se agregan o quitan directamente las propiedades que han cambiado. A continuación, se actualiza la configuración del modelo para abordar los cambios en la manera en que la base de datos se asigna a las clases existentes.
Personalización de la generación de código
EF Core 6 no admite actualmente la personalización del código generado. Hay soluciones de terceros disponibles para ello, como EF Core Power Tools. Para obtener una lista de las herramientas y extensiones destacadas de la comunidad, consulte: Herramientas y extensiones de EF Core.
Por último, revise la lista detallada de diferencias entre EF6 y EF Core para solucionar otros problemas con la migración.
