Linq to SQL: ¿Es mejor tener un pequeño DataContext para cada página o una global?

Question

Estoy probando Linq a SQL en una aplicación ASP.NET que utiliza una gran base de datos con muchas claves externas (más de 100 tablas). Estoy impresionado con la forma en que Linq te permite crear un contexto de datos con todas tus relaciones intactas y luego crear sentencias Linq que unen mesas automáticamente. Sin embargo, esto lleva a una pregunta: si presento una declaración de Linq que solo funciona con una o dos tablas, ¿es mejor tener un contexto de datos que solo tenga las tablas/tablas necesarias? Me parece que si construyo un contexto de datos con todas las tablas en la base de datos, sería bastante masivo y cargarlo para cada uso de Linq tendría un impacto negativo en el rendimiento. ¿Estoy en lo cierto?

Comentario: Sé crear el contexto de datos solo cuando sea necesario (pero gracias, no obstante, por mencionarlo). La pregunta realmente es si debería tener muchos pequeños datos de contexto o si sería correcto construir uno grande.

Answer 1

Debe tener un DataContext por cada grupo de tablas conectadas. En la mayoría de las aplicaciones, esto significa un DataContext para todo. Si tiene varios conjuntos de tablas que no necesita modificar juntos, puede considerar varios DataContexts. Si incluso podría realizar una consulta en DataContexts, no los separe.

Un DataContext no es sólo un conjunto de tablas - que está destinado a ser una implementación del patrón de puerta de enlace de datos - se puede llenar con métodos que devuelven los datos que necesita, por lo que no tiene que codificar consultas en cada rincón de tu aplicación. Ahora bien, si tuviera múltiples DataContexts, uno por página, muy probablemente terminaría teniendo que incluir su funcionalidad común (piense en MyDataContext.GetActiveCustomers()) en cada uno de ellos. Esta sería una horrible duplicación.

Así que la respuesta es que generalmente no está bien construir muchos DataContexts pequeños. Esto solo es posible si sus datos están completamente separados (diferentes bases de datos lógicas o físicas) o si está utilizando DataContext como simplemente un objeto Connection, que no debe ser. No obstante, tenga en cuenta que los DataContexts deben ser efímeros: son una implementación del patrón de Unidad de trabajo y, por lo tanto, su duración debe ser igual a una operación lógica (por ejemplo, cargar un conjunto de productos o insertar un pedido nuevo). . Los DataContexts son baratos de crear y destruir, así que no pierdas tiempo almacenándolos en caché solo porque sí.

Answer 2

En esta página http://www.albahari.com/nutshell/10linqmyths.aspx (consulte el mito n.º 10) dice que es mejor utilizar instancias de DataContext de corta duración.

Answer 3

Creo que el contexto de los datos es bastante ligero, en su mayoría solo contenedores. Los datos no se cargan en el contexto hasta que lo consulta. No creo que sea incorrecto tener un único contexto de datos, sino solo crear una instancia según sea necesario (como una unidad de trabajo) en lugar de mantenerlo todo el tiempo. De esta forma, no tienes un objeto de larga vida que pueda seguir creciendo más y más.

Si sus tablas se pueden separar en grupos de tablas relacionados, es posible que desee considerar tener un contexto de datos separado para cada uno de estos grupos. No estoy seguro de cómo LINQ manejaría una consulta utilizando datos de contextos múltiples, pero parece que debería funcionar siempre y cuando las tablas estén en el mismo servidor. Tendría que comprobar esto si dividía las cosas en varios contextos y tenía consultas que necesitaban tablas de más de una.

Normalmente utilizo un contexto único y lo instanciado según sea necesario, pero no tengo ninguna base de datos tan grande como la suya.

Answer 4

Hice una prueba en nuestra base de datos que tiene alrededor de 600 tablas.Primero, los dividí en 9 contextos de datos discretos que fueron bastante manejables. Luego escribí un script que seleccionó, actualizó y eliminó unos cientos de veces en uno de ellos (eliminando el contexto de datos después de cada uno, por lo que LINQ se vio forzado a recrearlo para cada acceso).

Luego hice otro contexto de datos que tenía las 600 tablas directamente en él y ejecuté la misma prueba.

Los resultados fueron prácticamente idénticos. Mi conclusión fue que no se obtuvo ganancia de rendimiento de los contextos de datos más pequeños. Y, sin duda, es mucho más fácil trabajar con entidades que provienen de un solo contexto de datos (¡aunque no en la vista del diseñador, phew!).