gran base de datos es siempre algo especial. Cualquier tecnología tiene algunos pros y contras cuando se trabaja con una gran base de datos.
El problema encontrado es el más probablemente relacionado con la construcción del modelo. Cuando inicie la aplicación y use elementos relacionados con EF por primera vez, EF debe compilar la descripción del modelo y compilarla; esta es la operación que más tiempo consume en EF. La complejidad de esta operación crece con el número de entidades en el modelo. Una vez que se compila el modelo, se reutiliza durante toda la vida útil de la aplicación (si reinicia la aplicación o descarga el dominio de la aplicación, el modelo debe compilarse nuevamente). Puede evitar esto precompilando el modelo. Se realiza en el momento del diseño, donde utiliza alguna herramienta para generar código a partir del modelo e incluye ese código en su proyecto (debe volver a realizarse después de cada cambio en el modelo). Para los modelos basados en EDMX puede usar EdmGen.exe para generar vistas y para los modelos basados en el código primero puede usar EF Power Tools CTP1.
EDMX (el diseñador) fue mejorada en VS 2010 SP1 para poder trabajar con modelos de gran tamaño, pero sigo pensando que el gran en este caso es de alrededor de 100 entidades/tablas. Al mismo tiempo, rara vez necesita 715 tablas en el mismo modelo. Creo que estas tablas 715 realmente modelan varios dominios, por lo que puedes dividirlos en varios modelos.
Lo mismo es cierto cuando se utiliza DbContext y el código en primer lugar. Si modelas una clase, ¿crees que es un diseño correcto cuando la clase expone 715 propiedades? No lo creo, pero eso es exactamente lo que parece su DbContext
derivado: tiene una propiedad pública para cada conjunto de entidades expuestas (en el mapeo más simple significa una propiedad por tabla).
La misma entidad se puede utilizar en varios modelos, pero debe intentar evitarla tanto como sea posible, ya que puede presentar algunas complejidades al cargar entidades en un tipo de contexto y usarlas en otro tipo de contexto.
Código única = código de primera = marco de la entidad cuando se define el mapeo en el código sin utilizar EDMX.
Además de lo que sugirió @Ladislav, pienso hacer edmx sobre la base de módulos puede ayudar en este escenario, al igual que para admin tener edmx separada, por otro módulo de compras edmx de manera similar para otros módulos – Deepesh
He instalado el Poder EF herramientas y creó un modelo de solo código de la base de datos existente. Esto ciertamente parece funcionar mejor que tener el EDMX. Sin embargo, todavía tengo el problema de que agregar un registro envía el programa a lala. ¿Cómo puedo averiguar qué está yendo mal? –
Los contextos múltiples te meten en problemas cuando utilizas EF Migrations, porque eso espera una base de datos == un contexto, ¿sí? –