Puerto de EF6 a EF Core: base de datos como origen de la verdad

Si usa la base de datos como origen de la verdad, la actualización implicará principalmente abordar los cambios en la forma de las entidades generadas. Los pasos para migrar incluyen:

1. Elija un momento dado para modelar la base de datos.
2. Asegúrese de que los proyectos de EF6 están actualizados y sincronizados con la base de datos.
3. Cree el proyecto de EF Core.
4. Utiliza las herramientas de scaffolding para realizar la ingeniería inversa de tu base de datos a código.
5. Valide que las clases generadas por EF Core sean compatibles con el código.
6. Para las excepciones, modifique las clases generadas y actualice la configuración del modelo o adapte el código al modelo.

Tenga en cuenta que, aunque EF Core actualmente genera todo lo necesario para crear correctamente una copia de la base de datos, gran parte del código no es necesario para el enfoque basado en la base de datos. Se está realizando un seguimiento de la corrección de esto bajo 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 de esquema

Cuando la base de datos es la fuente de verdad, EF Core obtiene la 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. Un conjunto de pruebas completo es útil para este enfoque, ya que puede automatizar el proceso de andamiaje y comprobar los cambios mediante la ejecución de las pruebas.

Sugerencias para controlar las diferencias del modelo

Por varias razones, es posible que desee que el modelo de dominio de C# tenga una forma diferente a la generada en ingeniería inversa. En muchos casos, esto significa actualizar manualmente el código que se genera automáticamente después de cada cambio de esquema. Una manera de evitar el esfuerzo adicional cuando se vuelve a generar el código es usar clases parciales para DbContext y entidades relacionadas. A continuación, puede mantener el código relacionado con la lógica de negocios y las propiedades no rastreadas en la base de datos en un conjunto independiente de archivos de clase que no se sobrescribirán.

Si el modelo es significativamente diferente del generado, pero no cambia con frecuencia, una opción que se debe tener en cuenta es el uso del patrón de repositorio como 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 desee considerar un flujo de trabajo alternativo y seguir los 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, actualice la configuración del modelo para abordar los cambios en la forma 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 como EF Core Power Tools que están disponibles. Para obtener una lista de las herramientas y extensiones de la comunidad destacadas, consulte: EF Core Tools and Extensions( Herramientas y extensiones de EF Core).

Por último, revise la lista detallada de diferencias entre EF6 y EF Core para solucionar los problemas restantes con la portabilidad.