¿Son varias las clases de DataContext apropiadas?

Question

Para utilizar completamente LinqToSql en una aplicación ASP.net 3.5, es necesario crear DataContextclasses (que generalmente se realiza utilizando el diseñador en VS 2008). Desde la perspectiva de la interfaz de usuario, DataContext es un diseño de las secciones de su base de datos a las que le gustaría exponer a través de LinqToSql y es integral en la configuración de las características de ORM de LinqToSql.

Mi pregunta es: estoy configurando un proyecto que utiliza una gran base de datos donde todas las tablas están interconectadas de alguna manera a través de claves externas. Mi primera inclinación es hacer una gran clase de DataContext que modele toda la base de datos. De esa manera podría en teoría (aunque no sé si esto sería necesario en la práctica) usar las conexiones de clave externa que se generan a través de LinqToSql para ir fácilmente entre objetos relacionados en mi código, insertar objetos relacionados, etc.

Sin embargo, después de pensarlo un poco, ahora estoy pensando que puede tener más sentido crear múltiples clases de DataContext, cada una relacionada con un espacio de nombre específico o una sección lógica interrelacionada dentro de mi base de datos. Mi principal preocupación es que crear instancias y eliminar una gran clase de DataContext todo el tiempo para las operaciones individuales que se relacionan con áreas específicas de la base de datos sería imponer una imposición innecesaria sobre los recursos de la aplicación. Además, es más fácil crear y administrar archivos DataContext más pequeños que uno grande. Lo que perdería sería que habría algunas secciones distantes de la base de datos que no serían navegables a través de LinqToSql (aunque una cadena de relaciones las conecta en la base de datos real). Además, habría algunas clases de tabla que existirían en más de un DataContext.

¿Alguna idea o experiencia sobre si múltiples DataContexts (correspondientes a los espacios de nombres DB) son apropiados en lugar de (o además de) una clase DataContext muy grande (correspondiente a la base de datos completa)?

Answer 1

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

Lifetime of a LINQ to SQL DataContext

Los cuatro puntos principales de esta entrada del blog son que DataContext:

1. es ideal para una "unidad de trabajo" enfoque
2. También está diseñado para operación de servidor "sin estado"
3. No está diseñado para Uso de larga vida

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

Teniendo en cuenta que, no creo que el uso de más de un DataContext haría cualquier harm- de hecho, la creación de diferentes DataContexts para diferentes tipos de trabajo ayudaría a que su impelmentation LinqToSql más asimilable y organizada. El único inconveniente es que no podrías usar sqlmetal para autogenerar tu dmbl.

Answer 2

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. Entonces, si tuviera que usar múltiples almacenes de datos, necesitaría usar múltiples DataContexts. Mi reacción instintiva es que no notarías una desaceleración con un DataContext que abarca una gran cantidad de tablas. Sin embargo, si lo hiciera, siempre podría dividir la base de datos lógicamente en puntos en los que puede aislar tablas que no tienen ninguna relación con otros conjuntos de tablas y crear contextos múltiples.

Answer 3

He estado discutiendo sobre la misma pregunta mientras retro ajustaba LINQ a SQL sobre un DB heredado. Nuestra base de datos es un poco "whopper" (150 tablas) y después de reflexionar y experimentar elegí utilizar múltiples DataContexts. Si esto se considera un antipatrón queda por verse, pero por ahora hace que la vida sea manejable.

Answer 4

Creo que John es correcto.

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

¿Cómo apoya que ¿declaración? ¿Cuál es su experimento que muestra que un DataContext grande es un cuello de botella de rendimiento? Tener múltiples datacontexts es muy parecido a tener múltiples bases de datos y tiene sentido en escenarios similares, es decir, casi nunca. Si está trabajando con múltiples contextos de datos, necesita realizar un seguimiento de qué objetos pertenecen a qué contexto de datos y no puede relacionar objetos que no están en el mismo contexto de datos. Ese es un olor costoso de diseño sin ningún beneficio real.

@Evan "DataContext (o Linq to Entities ObjectContext) es más una" unidad de trabajo "que una conexión" Es precisamente por eso que no debe tener más de un contexto de datos. ¿Por qué querrías más esa "unidad de trabajo" a la vez?

Answer 5

Tengo que estar en desacuerdo con la respuesta aceptada. En la pregunta planteada, el sistema tiene una sola base de datos grande con fuertes relaciones de clave externa entre casi todas las tablas (también el caso donde yo trabajo). En este escenario, dividirlo en DataContexts más pequeños (DC) tiene dos inconvenientes inmediatos e importantes (ambos mencionados por la pregunta):

1. Se pierde relaciones entre algunas tablas. Puede tratar de elegir sus límites DC sabiamente, pero eventualmente se encontrará con una situación en la que sería muy conveniente usar una relación de una tabla en un DC a una tabla en otro, y no podrá hacerlo.
2. Algunas tablas pueden aparecer en varios DC. Esto significa que si desea agregar métodos de ayuda específicos de la tabla, lógica de negocios u otro código en clases parciales, los tipos no serán compatibles en todos los DC. Puede solucionar esto heredando cada clase de entidad de su propia clase base específica, que se vuelve desordenada. Además, los cambios de esquema deberán duplicarse en varios DC.

Ahora esos son inconvenientes significativos. ¿Hay ventajas lo suficientemente grandes como para superarlos?La pregunta menciona rendimiento:

Mi principal preocupación es que crear instancias y disponer una enorme clase DataContext todo el tiempo para las operaciones individuales que se relacionan a áreas específicas de la base de datos sería imponer una innecesaria imposición a los recursos de aplicaciones.

En realidad, no es cierto que un DC grande requiera mucho más tiempo para crear instancias o utilizarlo en una unidad de trabajo típica. De hecho, after the first instance is created in a running process, subsequent copies of the same DC can be created almost instantaneously.

La única ventaja real de varios DC para una única base de datos grande, con relaciones de clave externa a fondo es que se puede compartimentar su código un poco mejor. Pero ya puedes hacer esto con clases parciales.

Además, la unidad de concepto de trabajo no es realmente relevante a la pregunta original. Unidad de trabajo normalmente se refiere a la cantidad de un trabajo de un solo DC ejemplo está haciendo, no la cantidad de trabajo un DC clase es capaz de hacer.