entity framework - tutorial - Combine primero el código y la base de datos en un solo modelo?

mostrar datos entity framework

Question

¿Hay alguna forma de combinar código primero y base de datos primero en el mismo contexto? Nos encontramos con problemas masivos de rendimiento en el tiempo de desarrollo cuando editamos el archivo EDMX (se tarda 1.5 minutos en guardar). Trasladé nuestras UDF / procesos almacenados que no son de inserción / actualización / eliminación a algunas plantillas T4 personalizadas que generan automáticamente el primer código de modelo, pero parece que no se puede llamar a OnModelCreating cuando se trata de EDMX.

Otras cosas que hemos considerado, pero que no funcionarán por una razón u otra:

1. No podemos (razonablemente) separar nuestro código en contextos múltiples ya que hay mucha superposición en las relaciones de nuestra entidad. También parece que toda la gente que se ha ido esta ruta lo lamenta.

2. Intentamos tener 2 contextos diferentes, pero hay bastantes combinaciones entre Entidades y UDF. Esta puede ser nuestra última esperanza, pero REALMENTE quisiera evitarla.

3. No podemos cambiar a Dapper ya que lamentablemente hemos hecho un uso intensivo de IQueryable .

4. Intentamos ir completamente a Code-First, pero hay funciones que estamos usando en EDMX que no son compatibles (principalmente relacionadas con insertar / actualizar / eliminar la asignación de procedimientos almacenados).

Answer 1

También parece que un buen número de personas que han tomado esta ruta [contextos múltiples] lo lamentan.

No soy uno de ellos.

Su problema central es un contexto que se vuelve demasiado grande. Así que desglosa eso. Sé que inevitablemente habrá entidades que deberían compartirse entre varios contextos, lo que puede dar lugar a nombres de clases duplicados. Una manera fácil de resolver esto es cambiar el nombre de las clases en sus nombres específicos del contexto.

Por ejemplo, tengo una tabla ApplicationUser (que no) que se asigna a una clase con el mismo nombre en el contexto principal, pero a una clase AuthorizationUser en mi AuthorizationContext , o ReportingUser en un ReportingContext . Esto no es un problema en absoluto . La mayoría de los casos de uso giran en torno a un tipo de contexto de todos modos, por lo que es imposible confundirse.

Incluso tengo contextos especializados que trabajan con los mismos datos que otros contextos, pero de una manera más económica. Por ejemplo, un contexto que no se correlaciona con columnas calculadas en la base de datos, por lo que no hay lecturas después de las inserciones y actualizaciones (aparte de los valores de identidad).

Así que recomendaría ir por eso, porque ...

¿Hay alguna forma de combinar código primero y base de datos primero en el mismo contexto?

No, no hay. Ambos enfoques tienen diferentes formas de construir el DbModel (que contiene el modelo de tienda, el modelo de clase y las asignaciones entre ambos). En un DbContext generado incluso ves que se lanza una DbContext , para llevar a casa que no debes usar ese método.

mayormente relacionado con insertar / actualizar / eliminar mapeo de procedimientos almacenados

Como se dijo en otra respuesta, el mapeo de acciones de CUD para procedimientos almacenados se admite primero en código EF6 .

Answer 2

Eche un vistazo al siguiente enlace. Respondí otra pregunta de manera similar:
Cómo utilizar el patrón Repository utilizando el primer enfoque de la Base de datos en el marco de la entidad

Como mencioné en esa publicación, personalmente intenté cambiar a un enfoque Code First y deshacerme de los archivos EDMX ya que ya están en desuso y, lo que es más importante, el esfuerzo de mantenimiento es considerable y mucho más complejo en comparación con el enfoque Code First.

No es tan difícil cambiar a Code First desde un enfoque Model First. Algunos pasos e imágenes abajo:

1. Visualice todos los archivos en el nivel del proyecto y expanda el archivo EDMX. Notará que el archivo EDMX tiene un archivo .TT que tendrá varios archivos anidados, el Contexto del modelo y las clases POCO entre ellos como clases .cs o .vb (según el idioma que esté utilizando). Ver imagen abajo:
   
2. Descargue el proyecto, haga clic derecho y luego edite.
3. Vea la imagen a continuación, observe las dependencias entre el contexto y el archivo TT
   
4. Elimine las dependencias, el elemento xml debería verse como la imagen siguiente:
   
5. Repita el procedimiento para las clases de modelo (las que tienen la definición del modelo)
6. Recargue su proyecto, elimine el (los) archivo (s) EDMX
7. Probablemente necesites hacer algunas modificaciones y actualizar nombres / referencias.

Lo hice algunas veces en el pasado y funcionó a la perfección en la producción. También puede buscar las herramientas que hacen esta conversión por usted.

Esta podría ser una buena oportunidad para que reconsidere la arquitectura también.

Por cierto: el punto de viñeta 4 no debe ser un stop de espectáculo para ti. Puede asignar / usar procedimientos almacenados a través de EF. Mira el siguiente enlace:
¿Cómo llamar al procedimiento almacenado en Entity Framework 6 (Code-First)?

Answer 3

Gracias a todos por las respuestas bien pensadas y completas.

Muchas de estas otras respuestas suponen que las asignaciones de procedimientos almacenados en EF Code-First funcionan de la misma manera, pero no es así. Estoy un poco confuso sobre esto, ya que han pasado unos 6 meses desde que lo analicé, pero creo que a partir del código EF 6.3, los primeros procedimientos almacenados requieren que pase cada columna de su entidad a su procedimiento insert / update almacenado y que usted solo pase la (s) columna (s) clave a su procedimiento de eliminación. No hay una opción para escoger y elegir qué columnas puedes pasar. Tenemos el requisito de mantener quién borró un registro, así que tenemos que pasar información adicional además de una simple clave.

Dicho esto, lo que terminé haciendo fue utilizar una plantilla T4 para generar automáticamente mis archivos EDMX / Context / Model de la base de datos (con algunos metadatos adicionales). Esto redujo nuestra experiencia de tiempo de desarrollador de 1.5 minutos a aproximadamente 5 segundos.

Mi esperanza es que las correlaciones de procedimientos almacenados de EF se mejoren para lograr la parodia con EDMX y, a continuación, puedo generar código de las asignaciones de Código Primero y eliminar por completo la generación de EDMX.

Answer 4

Llegué de un enlace en su comentario sobre una pregunta diferente, donde me preguntó:

Usted mencionó que primero el código primero y la base de datos es "técnicamente posible", ¿podría explicar cómo lograr eso?

Primero, el contexto de la otra pregunta era completamente diferente. El PO estaba preguntando si era posible usar las metodologías de primero en la base de datos y primero en el código en el mismo proyecto, pero importante, no necesariamente en el mismo contexto. Mi afirmación de que era "técnicamente posible" se aplica a la primera, no a la segunda. No hay absolutamente ninguna forma de utilizar primero el código primero y la base de datos primero en el mismo contexto. En realidad, para ser un poco más específico, digamos que no hay forma de utilizar una base de datos existente y también migrar esa misma base de datos con nuevas entidades.

La terminología se confunde aquí debido a algunos nombramientos desafortunados de Microsoft cuando se estaba desarrollando EF. Originalmente, solo tenía Primero modelo y Primero base de datos. Ambos utilizaron EDMX. La única diferencia era que Model-first le permitía diseñar sus entidades y crear una base de datos a partir de eso, mientras que Database-first tomaba una base de datos existente y creaba entidades a partir de eso.

Con EF 4.1, se introdujo Code-first, que descartó EDMX por completo y le permitió trabajar con POCO (objetos simples de clase antigua). Sin embargo, a pesar del nombre, Code-first puede y siempre ha sido capaz de trabajar con una base de datos existente o crear una nueva. Código primero, luego es realmente el modelo primero y el primero de la base de datos, combinados, menos el horrible EDMX. Recientemente, el equipo de EF finalmente ha dado un paso más y ha dejado de usar EDMX por completo, incluidas las metodologías de modelo primero y de base de datos. No se recomienda continuar utilizando ninguno de los dos en este momento, y puede esperar que el soporte de EDMX se descarte por completo en futuras versiones de Visual Studio.

Con todo lo dicho, vamos con los hechos. No se puede tener una base de datos existente y una base de datos administrada por EF en un solo contexto. Al menos necesitaría dos: una para las tablas existentes y otra para las administradas por EF. Más al punto, estos dos contextos deben hacer referencia a diferentes bases de datos. Si hay tablas existentes en una base de datos manejada por EF, EF intentará eliminarlas. De largo y corto, debe segregar sus cosas administradas por EF de sus cosas administradas externamente, lo que significa que no puede crear claves foráneas entre entidades en un contexto y otro.

Su única opción real aquí es simplemente hacer todo "base de datos primero". En otras palabras, solo tendrá que tratar su base de datos como existente y crear manualmente nuevas tablas, modificar columnas, etc. sin depender en absoluto de las migraciones de EF. En este sentido, también debe seguir adelante y volcar el EDMX. Genere todas sus entidades como POCO y simplemente desactive el inicializador de base de datos en su contexto. En otras palabras, código primero con una base de datos existente. Tengo información adicional , si la necesitas.