Son Múltiples DataContext clases siempre la adecuada?

Question

Con el fin de utilizar plenamente LinqToSql en un ASP.net 3.5 aplicación, es necesario crear DataContext clases (que normalmente se realiza mediante el diseñador en VS 2008).Desde la perspectiva de interfaz de usuario, el DataContext es un diseño de las secciones de la base de datos que te gustaría exponer a través de LinqToSql y es una parte integral en la creación de la ORM características de LinqToSql.

Mi pregunta es:Estoy configurando un proyecto que utiliza una gran base de datos donde todas las mesas están interconectados de alguna manera a través de Claves foráneas.Mi primer impulso es hacer una enorme clase DataContext que los modelos de la base de datos completa.De esa manera, yo podría, en teoría (aunque no sé si esto sería necesario en la práctica) el uso de la Clave externa de las conexiones que se generan a través de LinqToSql para ir fácilmente entre los objetos relacionados con mi código, insertar objetos relacionados, etc.

Sin embargo, después de pensarlo, ahora estoy pensando que puede tener más sentido para crear múltiples DataContext clases, cada una relativa a un determinado espacio de nombres lógico o interrelacionados sección dentro de mi base de datos.Mi principal preocupación es que las instancias y de disponer de una enorme clase DataContext todo el tiempo para las operaciones individuales que se refieren a áreas específicas de la Base de datos sería imponer una innecesaria la imposición sobre los recursos de la aplicación.Además, es más fácil crear y administrar pequeñas DataContext archivos de un grande.La cosa que iba a perder, es que habría un lejano secciones de la base de datos que no sería navegable a través de LinqToSql (aunque de una cadena de relaciones que les conecta en la base de datos real).Además, habrá algún tipo de tabla de clases que existen en más de un DataContext.

Cualquier pensamiento o la experiencia en si varios DataContexts (correspondiente a la DB espacios de nombres) son apropiados, en lugar de (o además) de una gran clase DataContext (correspondiente a toda la base de datos)?

Answer 1

No estoy de acuerdo con la respuesta de Juan.El DataContext (o Linq to entities ObjectContext) es más de una "unidad de trabajo" de una conexión.Gestiona el seguimiento de cambios, etc.Esta entrada del blog para una descripción:

Tiempo de vida de una LINQ to SQL DataContext

Los cuatro puntos principales de este blog son que DataContext:

1. Es ideal para una "unidad de trabajo" enfoque
2. También está diseñado para "apátridas" de funcionamiento del servidor
3. No está diseñado para Larga vida de uso

4. Should be used very carefully after
   any SumbitChanges() operation.
   

Teniendo en cuenta que, yo no creo que el uso de más de un DataContext haría ningún daño - de hecho, la creación de diferentes DataContexts para diferentes tipos de trabajo podría ayudar a hacer que su LinqToSql impelmentation más usuable y organizado.La única desventaja es que usted no será capaz de utilizar sqlmetal para auto-generar su dmbl.

Answer 2

Yo había estado forcejeando sobre la misma cuestión, mientras que retrofitting LINQ to SQL a través de un legado DB.Nuestra base de datos es un poco de un whopper (150 tablas) y después de un poco de pensamiento y experimentación que decidí usar múltiples DataContexts.Si esto se considera un anti-patrón aún está por verse, pero por ahora se hace la vida más manejable.

Answer 3

Yo creo que Juan es correcta.

"Mi principal preocupación es que las instancias y de disponer de una enorme clase DataContext todo el tiempo para las operaciones individuales que se refieren a áreas específicas de la Base de datos sería imponer una innecesaria la imposición sobre la aplicación de los recursos"

¿Cómo se puede apoyar esta afirmación?¿Cuál es el experimento que muestra que un gran DataContext es un cuello de botella de rendimiento?Tener múltiples datacontexts es muy parecido a tener varias bases de datos y tiene sentido en situaciones similares, es decir, casi nunca.Si usted está trabajando con varios datacontexts que usted necesita para mantener un seguimiento de qué objetos pertenecen a la cual datacontext y no se puede relacionar objetos que no están en el mismo contexto de datos.Que es un diseño costoso olor de ningún beneficio real.

@Evan "El DataContext (o Linq to entities ObjectContext) es más de una "unidad de trabajo" de una conexión" Es precisamente por eso que usted no debe tener más de un datacontext.¿Por qué quieres más que una "unidad de trabajo" en un momento?

Answer 4

Tengo que estar en desacuerdo con la aceptada respuesta.En la pregunta, el sistema tiene una única base de datos grande con fuertes relaciones de clave externa entre casi todos los de la tabla (también en el caso de donde yo trabajo).En este escenario, romperlo en pequeñas DataContexts (DC) tiene dos inmediatos y graves inconvenientes (ambos citados por la pregunta):

1. A perder las relaciones entre algunas tablas. Usted puede tratar de elegir tu DC límites sabiamente, pero eventualmente ejecutar en una situación en la que sería muy conveniente el uso de una relación de una tabla en un DC a una tabla en otra, y usted no será capaz de.
2. Algunas tablas pueden aparecer en múltiples DC. Esto significa que si usted desea agregar específicos de la tabla métodos auxiliares, lógica del negocio, u otro código de las clases parciales, los tipos no será compatible a través de DC.Usted puede evitar este heredando cada clase de entidad a partir de su propia y específica de la clase base, que consigue sucio.También, los cambios de esquema tendrá que ser duplicada a través de múltiples DC.

Ahora bien, estas son importantes inconvenientes.Existen ventajas lo suficientemente grande como para superarlos?La pregunta menciona rendimiento:

Mi principal preocupación es que las instancias y de disponer de una enorme Clase DataContext todo el tiempo para las operaciones individuales que se relacionan para áreas específicas de la Base de datos sería imponer un innecesario la imposición sobre los recursos de la aplicación.

En realidad, no es cierto que una gran DC lleva mucho más tiempo para crear una instancia o su uso en una unidad típica de trabajo.De hecho, después de crear la primera instancia de un proceso en ejecución, posterior copias de la misma DC puede ser creado de forma casi instantánea.

La única ventaja real de múltiples DC es para una sola, gran base de datos completa de relaciones de clave externa es que se puede compartimentar el código un poco mejor.Pero ya se puede hacer esto con las clases parciales.

También, la unidad de concepto de trabajo no es realmente relevante a la pregunta original.Unidad de trabajo normalmente se refiere a la cantidad de trabajo de un único DC ejemplo está haciendo, no la cantidad de trabajo que un DC clase es capaz de hacer.

Answer 5

En mi experiencia con LINQ to SQL y LINQ to entities un DataContext es sinónimo de una conexión a la base de datos.Así que si usted fuera a utilizar varios almacenes de datos que usted necesita para el uso de varios DataContexts.Mi reacción instintiva es que no se notará mucho de una desaceleración con un DataContext que abarca un gran número de tablas.Si usted no obstante, siempre se puede dividir la base de datos, lógicamente, en los puntos donde se puede aislar de las tablas que no tienen ninguna relación con otros conjuntos de mesas y crear múltiples contextos.