2011-05-31 15 views
11

Estoy desarrollando una capa de acceso de datos para una base de datos con más de 700 mesas. Creé el modelo que incluye todas las tablas, lo que generó un gran modelo. Luego cambié el modelo para usar DBContext de 4.1, que parecía mejorar la compilación y el funcionamiento. El diseñador no parecía funcionar en absoluto.Entity Framework 4.1 para gran número de tablas (715)

Entonces creé una aplicación de prueba que se agregó dos registros a la tabla, pero el procesador fue 100% en el método db.SaveChanges. Al ser una caja negra, fue difícil determinar qué salió mal.

Así que mis preguntas son

  1. es el marco entidad la mejor aproximación a una gran base de datos
  2. Si es así, el modelo debe ser dividido en áreas lógicas. Me di cuenta de que no puede tener la misma tabla sql en varios modelos
  3. He leído que el enfoque de solo código es el mejor en estos casos grandes. Que es eso.

Cualquier orientación sería verdaderamente apreciado

Gracias

Respuesta

12

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.

+0

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

+0

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? –

+0

Los contextos múltiples te meten en problemas cuando utilizas EF Migrations, porque eso espera una base de datos == un contexto, ¿sí? –

Cuestiones relacionadas