Decisión de diseño: múltiples archivos EF EDMX

Question

Si ha utilizado Entity Framework, sabrá que el EDMX es genial. También sabe que puede volverse ENORME y casi ingobernable.

Cuando se vuelve grande, es tentador crear un segundo EDMX o un tercero, incluso uno para cada esquema en su base de datos (solo como ejemplo).

Dicha separación ayudaría con la organización de su EDMX, pero podría separar el contexto de las entidades en el mismo espacio de nombres.

Además, archivos EDMX separados pueden crear una situación en la que una operación JOIN en archivos EDMX produce una comunicación excesiva y redundante de la base de datos.

Pero, el hecho es que cuanto más grande es el EDMX, más difícil es de usar. Lo más difícil es asegurar que sea correcto. Más fácil es romperse.

¿Se rompen los archivos EDMX aparte? ¿Tiene una regla de oro para cuándo?

Answer 1

Un ejemplo de la necesidad de dividir su EDMX sería si usted tiene un grupo de entidades que se utilizan en más de un proyecto, mientras que otros son específicos de cada proyecto y que están dispuestos a renunciar a tener propiedades de navegación entre el partes (y permanecen solo con FK expuestas).

Puede fusionar automáticamente los EDMX en uno si desea mantenerlos por separado, pero abrir un contexto para todos ellos y consultarlos como uno solo. Esto requiere que compartan el mismo espacio de nombres.

Answer 2

Hemos llegado al extremo de necesitar utilizar dos EDMX por separado en una sola solución. Esta separación se produjo para nosotros con un EDMX para entidades de modelo específicas de dominio y otra para las más comunes en todas nuestras soluciones (Pago como ejemplo). Lógicamente, podrías decir que esto para nosotros estaba en el nivel de esquema db, aunque esa no era la regla más difícil de la separación.

Si bien no teníamos un requisito para las uniones entre ellos, necesitábamos transacciones. Logramos esto con un UnitOfWorkContainer reutilizable que envolvería los contextos EF dentro de un TransactionScope. Los contextos se inyectarían a través de DI en el contenedor y solo usaríamos TransactionScope si hubiera más de un contexto en el contenedor.

El contenedor en sí implementó nuestra interfaz IUnitOfWork por lo que fue muy fácil de conectar a la base de código existente.