¿Son varias las clases de DataContext apropiadas?

votos
27

Para utilizar completamente LinqToSql en una aplicación ASP.net 3.5, es necesario crear clases DataContext (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 usa una gran base de datos donde todas las tablas están interconectadas de alguna manera a través de Foreign Keys. 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 pasar fácilmente entre los 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 (que corresponde a todo el DB)?

Publicado el 05/08/2008 a las 06:54
fuente por usuario
En otros idiomas...                            


5 respuestas

votos
1

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.

Respondida el 05/08/2008 a las 10:57
fuente por usuario

votos
4

Había 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.

Respondida el 05/08/2008 a las 23:51
fuente por usuario

votos
25

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. Consulte esta publicación en el blog para obtener una descripción:

Vida útil de un DataContext LINQ to SQL

Los cuatro puntos principales de esta publicación de blog son DataContext:

  1. Es ideal para un enfoque de "unidad de trabajo"
  2. También está diseñado para el funcionamiento del servidor "sin estado"
  3. No está diseñado para el uso de larga duración
  4. Should be used very carefully after
    any SumbitChanges() operation.
    

Teniendo eso en cuenta, no creo que el uso de más de un DataContext haría daño, de hecho, la creación de diferentes DataContexts para diferentes tipos de trabajo ayudaría a que su impulso LinqToSql sea más usable y organizado. El único inconveniente es que no podrías usar sqlmetal para autogenerar tu dmbl.

Respondida el 07/08/2008 a las 22:02
fuente por usuario

votos
3

Creo que John está en lo correcto

"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"

¿Cómo respaldas esa afirmació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?

Respondida el 27/08/2008 a las 02:11
fuente por usuario

votos
3

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

  1. Se pierde relaciones entre algunas tablas. Se puede tratar de elegir los límites de corriente continua con prudencia, pero es muy probable que ejecutar en una situación en la que sería muy conveniente utilizar una relación de una tabla en un DC a una tabla en otra, y usted no será capaz de hacerlo.
  2. Algunas tablas pueden aparecer en múltiples CC. Esto significa que si desea agregar métodos de la tabla específica de ayuda, la lógica de negocio, u otro código en las clases parciales, los tipos no van a ser compatibles en CC de. Puede solucionar este heredando cada clase de entidad de su propia clase base específica, que se complica. Además, los cambios de esquema tendrán que ser duplicado a través de múltiples CC.

Ahora bien, son inconvenientes importantes. ¿Hay ventajas suficientemente grande 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 con las áreas específicas de la base de datos sería imponer una imposición innecesaria de recursos de la aplicación.

En realidad, no es cierto que una gran DC tarda mucho más tiempo para crear una instancia o el uso en una unidad típica de trabajo. De hecho, después de que se crea la primera instancia en un proceso en ejecución, las copias posteriores de la misma CD se pueden crear de forma casi instantánea .

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 se puede hacer esto con las 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.

Respondida el 17/06/2014 a las 21:53
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more