asp.net - net - LINQ to SQL: ¿dónde vive su DataContext?

mvc c# sql server

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, DataContext el DataContext en el HttpContext actual, 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 DataContext por hilo parece complicado y potencialmente más problemático 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 ese DAO para que pueda update o delete más tarde, sin mencionar que hay algo desagradablemente obsceno en 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

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 2

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

Answer 3

Las pautas de la documentación de MSDN en la clase DataContext son las que recomendaría seguir:

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

Debido a que DataContext es IDisposable , me resulta más fácil crear y usar un DataContext en una declaración using dentro de un método, por lo que se puede eliminar de forma adecuada.

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

Answer 4

Inyección de dependencia.

Preferimos mantener nuestra capa empresarial ignorante de escenarios web versus escenarios 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 forma, 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 debe mezclar entidades linq de diferentes contextos de datos, y normalmente se mete en problemas si usa las entidades linq si el contexto de datos ha sido Dispose () ''d of.