net - Entity Framework 4: ¿Tiene sentido crear un solo diagrama para todas las entidades?

entity framework tutorial español

Question

Escribí algunas suposiciones con respecto al Entity Framework, luego algunas preguntas (así que corríjalas donde me equivoco) Estoy tratando de usar POCOs con EF 4.

Mis suposiciones:

• Solo puede existir un contexto de datos para un diagrama EF.
• Los contextos de datos pueden referirse a más de una entidad.
• Si tiene dos fuentes de datos, digamos MS SQL Server y Oracle, EF requiere dos diagramas diferentes para acceder a los datos.
• El contexto de datos del diagrama EF es la "Unidad de trabajo", que tiene un solo Guardar () para cualquier cosa en el diagrama. (Claro que podría envolverlo en una clase UnitOfWork, pero esencialmente tiene los mismos deberes).

Asumiendo que es correcto, aquí están mis preguntas:

• Si no mantiene todas las entidades en el mismo diagrama de EF, ¿cómo mantiene la integridad de los datos, ya que "Pedidos" no puede existir sin un "Cliente"? ¿Es esta únicamente una función del repositorio para cargar datos solo para verificar la integridad, o "intentamos / atrapamos" los errores de integridad referencial de la base de datos?

• ¿No crearías un diagrama de EF para cada Entidad? Por ejemplo, no esperaría que los cambios en un cliente y los cambios en un producto se escribieran juntos ya que no tienen nada que ver entre sí (tenerlos en el mismo diagrama haría que se escribieran juntos). ¿O es el alcance de un diagrama de EF para abarcar todas las entidades similares almacenadas en el mismo medio de almacenamiento?

¿Es la norma dividir las entidades así, o simplemente tener un solo diagrama que contenga todas las entidades? Pensaría lo último, pero el pensamiento está consiguiendo lo mejor de mí.

Answer 1

Me doy cuenta de que esta pregunta era sobre EF4, pero estoy seguro de que muchas personas que ahora están "haciendo el cambio" terminarán aquí a través de Google y leerán esto y la respuesta aprobada y tomarán decisiones basadas en eso aunque estén utilizando EF5 (o EF4.4 si está atascado en .Net 4.0)

EF5 permite múltiples diagramas por edmx. Este es un gran problema, al menos para mi equipo, porque nos permite separar visualmente las entidades sin requerir archivos edmx separados. Los puntos del Dr. Zim siguen siendo válidos, excepto (obviamente) la "superficie de diseñador desordenada".

Existen inconvenientes al tener varios archivos edmx, el más grande es que incluso si crea espacios de nombres separados para cada uno, no puede duplicar nombres de entidades. Sí, si realmente estás diseñando el "código primero" de tu sistema, entonces esto no debería ser un problema. Sin embargo, muchos (la mayoría) de nosotros estamos agregando EF a los sistemas existentes que ya están construidos sobre bases de datos relacionales que tienen normalización.

"Pero la normalización es algo bueno , ¿verdad?" Bueno, si está utilizando una base de datos relacional sí. "Pero, ¿por qué importa eso si estoy usando EF?" Una tabla "normalizada" común es la dirección. Posible escenario: Compañía (ubicación del negocio / oficina) y Contacto (podría ser un trabajador "remoto" para que no estén en la ubicación del negocio) y ambos tienen un FK que apunta a Dirección. Al usar un archivo edmx para la Compañía y otro para el Contacto (incluso con diferentes espacios de nombres) que incluyen la tabla de Direcciones, el código se compilará, pero en el tiempo de ejecución obtendrá esta belleza:

Multiple types with the name ''Address'' exist in the EdmItemCollection
in different namespaces. Convention based mapping requires unique names
without regard to namespace in the EdmItemCollection

Puede cambiar el mapeo que usa EF, pero luego tiene otros "problemas" al trabajar con la implementación y la mayoría de la gente usa el mapeo predeterminado para que foros como este no tengan muchas preguntas y respuestas pertinentes.

También puede cambiar el nombre del modelo para la tabla de direcciones a "ContactAddress" y "CompanyAddress" respectivamente, pero eso da la ilusión de que son tipos diferentes cuando realmente no lo son. Bien, son tipos diferentes en EF pero no en la base de datos y, como dije, la mayoría de nosotros "vivimos" en el mundo de agregar EF a un sistema existente con un almacén de datos existente que es una base de datos relacional.

Esta ya es una "respuesta" larga, así que me detendré aquí. Solo quería asegurarme de que las personas que aterrizaron aquí porque buscaron "edmx múltiple" y no se dieron cuenta de que hay una diferencia significativa entre EF4 y EF5 fueron informadas y se dieron cuenta de que podrían necesitar investigar un poco más.

Answer 2

Tener un EDM grande que contenga todas las entidades generalmente NO es una buena práctica y no se recomienda.
El uso de un EDM grande causará varios problemas, tales como:

Problema de rendimiento en los tiempos de carga de metadatos:
A medida que aumenta el tamaño de los archivos de esquema, también aumentará el tiempo que toma analizar y crear un modelo en memoria para estos metadatos.

Problema de rendimiento en la generación de vistas:
La generación de vistas es un proceso que compila la asignación declarativa proporcionada por el usuario en las vistas de Entity Sql del lado del cliente que se utilizarán para consultar y almacenar Entidades en la base de datos. El proceso se ejecuta la primera vez que ocurre una consulta o SaveChanges. El rendimiento del paso de generación de vistas no solo depende del tamaño de su modelo, sino también de cuán interconectado esté el modelo. Si dos Entidades están conectadas a través de una cadena de herencia o una Asociación, se dice que están conectadas. Del mismo modo, si dos tablas se conectan a través de una clave externa, se conectan. A medida que aumenta el número de entidades y tablas conectadas en sus esquemas, aumenta el costo de generación de vistas.

Superficie de diseño desordenada:
Cuando genera un modelo Edm a partir de un gran esquema de base de datos, la superficie del diseñador está desordenada con muchas Entidades y sería difícil entender cómo se ve su modelo Entidad en total. Si no tiene una buena visión general del modelo de entidad, ¿cómo lo va a personalizar?

La experiencia de Intellisense no es genial:
Cuando genere un modelo Edm a partir de una base de datos con, por ejemplo, 1000 tablas, obtendrá 1000 conjuntos de entidades diferentes. Imagine cómo sería su experiencia inteligente cuando escribe "contexto" en la ventana de código de VS.

Espacios de nombres CLR desordenados:
Dado que un esquema modelo tendrá un solo espacio de nombres EDM, el código generado colocará las clases en un solo espacio de nombres.

Para una discusión más detallada, eche un vistazo a Trabajar con modelos grandes en Entity Framework - Parte 1

Solución:
Si bien no hay una solución lista para usar para esto, pero sugiere que, en cambio, debería tener subconjuntos desconectados naturalmente en su modelo, lo que significa que en función de su modelo de dominio, debe crear diferentes conjuntos de modelos de dominio que contengan objetos relacionados, mientras que cada conjunto No está relacionado y desconectado del otro. Ninguna Clave extranjera en el medio podría ser una buena señal para la separación. Y esto tiene sentido porque en un modelo grande, normalmente su aplicación no requiere que todas las tablas de una base de datos se asignen a un Modelo de entidad para que funcione.

Incluso si este tipo de separación no es 100% posible, lo que significa que hay subconjuntos de tablas que tienen claves externas que van a otras tablas en la base de datos, aún es recomendable que las separe. Cuando haga esto, tendrá que asumir la responsabilidad de configurar la clave externa de manera adecuada. No habría ninguna propiedad de navegación que le permita obtener la Entidad que representa esta clave externa. Por supuesto, puede consultar manualmente esta Entidad en el otro contenedor si es necesario.

Además, para obtener algunos consejos y trucos sobre cómo puede dividir un modelo de entidad grande en modelos más pequeños mientras reutiliza tipos, eche un vistazo a: Trabajar con modelos grandes en Entity Framework - Parte 2

Acerca de su pregunta: Orden y Cliente pertenecen al mismo dominio natural y deben mantenerse en el mismo EDM. Como dije, puede dispersarlos en 2 modelos de datos de entidades diferentes, pero luego tiene que asumir la responsabilidad de establecer las claves externas apropiadas o obtendrá excepciones de tiempo de ejecución, de la misma manera, el Cliente y el Producto deben mantenerse en una entidad separada modelos de datos. Siguiendo estas reglas, puede crear un diseño de conjunto de dominios bien definido en su capa de acceso a datos.