tag route net mvc for data asp all asp.net .net linq-to-sql datacontext

asp.net - route - ¿Son múltiples las clases de DataContext apropiadas?



select asp-for asp-items (5)

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 ir 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 espacios de nombres de DB) son apropiados en lugar de (o además de) una clase de DataContext muy grande (que corresponde a todo el DB)?

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.

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?

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.

Estuve discutiendo sobre la misma pregunta mientras adaptaba retro LINQ to 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 ver, pero por ahora hace que la vida sea manejable.

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 (DC) más pequeños tiene dos inconvenientes inmediatos y mayores (ambos mencionados por la pregunta):

  1. Pierdes las 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 auxiliares específicos de la tabla, lógica comercial 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 el rendimiento:

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.

En realidad, no es cierto que un DC grande requiera mucho más tiempo para crear instancias o usarlo en una unidad de trabajo típica. De hecho, después de crear la primera instancia en un proceso en ejecución, se pueden crear copias subsiguientes de la misma DC casi instantáneamente .

La única ventaja real de múltiples DC para una sola base de datos grande con relaciones exhaustivas de claves foráneas es que usted puede compartimentar su código un poco mejor. Pero ya puedes hacer esto con clases parciales.

Además, el concepto de unidad de trabajo no es realmente relevante para la pregunta original. La unidad de trabajo generalmente se refiere a la cantidad de trabajo que realiza una sola instancia de DC, no a la cantidad de trabajo que una clase de DC puede hacer.