Instancia múltiple/única de Linq a SQL DataContext

Question

Tengo un proyecto con varias clases diferentes que consultan y modifican datos en un conjunto común de tablas. Configuré un archivo .dbml que nos proporciona una clase DataContext. Mi pregunta es si una sola instancia de DataContext debería ser utilizada por todos los objetos, o si varias instancias son seguras de usar. También me pregunto sobre la seguridad de subprocesos en el caso de un solo DataContext, y si el acceso a sus métodos debe sincronizarse.

Answer 1

Rick Strahl tiene un buen artículo sobre sus opciones: http://www.west-wind.com/weblog/posts/246222.aspx.

Ver también: LINQ to SQL - where does your DataContext live?.

Es posible que desee una estrategia ligeramente diferente para cada tipo de despliegue - web, escritorio, servicio de ventanas ...

resumido, las opciones son:

• Global DataContext - peligroso de multiproceso entornos (incluidas las aplicaciones web). Recuerde que no se garantiza que los miembros de la instancia sean seguros para subprocesos (de Bradley Grainger's answer arriba).
• DataContext por hilo: complicado. Si su DataContext realiza un seguimiento de los cambios, debe asegurarse de eliminarlos en el momento apropiado. Instaurar, almacenar y recuperar el DataContext es un problema.
• DataContext por acción atómica: pierde la capacidad de seguir los cambios ya que un DataContext crea un objeto mientras que otro lo actualiza o lo elimina. Adjuntar un objeto de datos a un nuevo DataContext puede no funcionar como esperaba.
• DataContext por objeto de datos: parece poco elegante porque tiene que preocuparse por DataContext en la creación de instancias (crear y adjuntar) y actualizar/eliminar (sacarlo del objeto de datos y usarlo).

He optado por un DataContext por objeto de datos. Puede que no sea la solución más elegante, pero funciona en todos los entornos de implementación.

Answer 2

Siempre escuché que debería usar una sola instancia del DataContext. Por lo general, creo una instancia singleton de mi DC en mi clase de lógica de negocios y la utilizo para todas mis consultas de linq.

Estoy seguro de que algunos de los gurús de linq que están aquí podrían darte las razones exactas de por qué deberías tener solo una instancia de tu clase de contexto de datos ... No estoy seguro.

Answer 3

El problema con el uso de un único objeto de contexto de datos es que puede tener problemas si ha agregado algunos cambios a su cola, y desea realizar un roll-back en algunos de esos cambios en cola.

Es por eso que utilizo un objeto de contexto de datos para cada una de mis clases - mi clase User tiene su propio contexto de datos, mi clase Application tiene su propio y así sucesivamente.

Este patrón elimina la mayoría de los problemas de realizar retrotracción en mis proyectos.

Answer 4

La clase DataContext es lo suficientemente liviana para que pueda crear una instancia una y otra vez. Esto hace que todo sea más simple cuando se accede a objetos de entidad dentro de un único método. Si necesita acceder a los mismos objetos LINQ desde diferentes clases y métodos, manteniéndolos unidos a DataContext para realizar un seguimiento, también está bien mantener una sola instancia.

Answer 5

Utilizo una nueva instancia de DataContext para cada transacción.

La reutilización de instancias antiguas puede ser problemático e inflará el contenido del DataContext, ya que cualquier elemento que se haya cargado en algún momento deberá rastrearse: la aplicación se volverá lenta y lenta, lo que aumentará la memoria.

Si necesita un artículo más largo que para una transacción, puede separarlo del DataContext clonando el elemento, y puede volver a conectarlo más tarde a un nuevo y nuevo DataContext usando Adjuntar().
Incluso puedo clonar un artículo, enviarlo a través de la red con WCF, recuperarlo en una llamada posterior, adjuntarlo a un nuevo DataContext y guardar los cambios (por supuesto, necesito una columna de marca de tiempo para esto).