LINQ to SQL: ¿dónde vive su DataContext?

Question

Estoy usando LINQ to SQL en una biblioteca de objetos de acceso a datos. La biblioteca se usa en contextos web (aplicación web/servicio web) y no web (servicio de Windows). Inicialmente, almacené el DataContext en el actual HttpContext, ya que me permitió administrar una unidad de trabajo bastante pequeña (una solicitud web) y evitar objetos globales en una aplicación web. Obviamente, esto no funciona en un servicio de Windows.

Rick Strahl tiene un buen artículo sobre la gestión de la vida útil de DataContext: http://www.west-wind.com/weblog/posts/246222.aspx. Desafortunadamente, no puedo decidirme acerca del mejor enfoque. Un DataContext global no funciona por las razones que menciona, un por-Thread DataContext parece complicado y potencialmente más problemas de lo que vale, y una instancia por objeto parece quisquillosa: pierde un poco de elegancia cuando coloca el DataContext utilizado para crear un DAO a eso DAO por lo que puede update o delete más tarde - sin mencionar, hay algo desagradablemente polla y huevo sobre la relación.

¿Alguien tiene experiencia personal que sugiera que un enfoque es mejor que otro? O mejor aún, ¿alguien tiene un cuarto o quinto enfoque que no estoy viendo? ¿Dónde está el mejor lugar para almacenar y administrar su DataContext?

Answer 1

Las directrices de la MSDN documentation on the DataContext class son lo que yo recomiendo lo siguiente:

En general, es una instancia de DataContext diseñado para una duración de una "unidad de trabajo", sin embargo su aplicación define ese término. Un DataContext es liviano y no es costoso para crear. Una aplicación LINQ to SQL típica crea instancias de DataContext en el ámbito del método o como un miembro de clases efímeras que representan un conjunto lógico de operaciones de bases de datos relacionadas .

Debido DataContext es IDisposable, me resulta más fácil de crear y utilizar un DataContext en un comunicado using en un único método, por lo que puede desecharse adecuadamente.

También tenga en cuenta que "no se garantiza que ningún miembro de instancia sea seguro para subprocesos", por lo que compartir uno DataContext entre varios subprocesos no sería aconsejable.

Answer 2

Estoy usando un contexto por subproceso. Es complicado de configurar, pero limpia todo lo que necesita para hablar con el DB.

Answer 3

Estoy usando httpcontext en escenarios web y contexto de subprocesos para todo lo demás. Creamos un pequeño marco para que el contexto de datos se abstraiga por completo del nivel de presentación/negocio.

Answer 4

Dependency Injection.

Preferimos mantener nuestra capa de negocio ignorante de los escenarios web y no web. En cambio, los objetos de la capa lógica empresarial toman una referencia DataContext en su constructor que (explícitamente) permite compartir el DataContext e (implícitamente) permite compartir los objetos de la entidad de los resultados de la consulta, ya que todos provienen del mismo contexto de datos.

También DataContexts implementa IDisposable, por lo que realmente necesita administrar su vida útil. Todos nuestros formularios web tienen una clase base, y parte de eso es una propiedad de contexto de datos (creada de forma perezosa).De esta manera, todo en una página puede compartirlo, que a menudo es el caso. El contexto se descarta manualmente en el evento OnUnload() de la página.

---

• no hay que mezclar las entidades LINQ a partir de diferentes contextos de datos, y normalmente se meten en problemas si utiliza las entidades LINQ si el DataContext ha sido Dispose() 'd de.