linq2sql: Singleton o el uso, las mejores prácticas

Question

lo que es la práctica preferida cuando linq2sql utilizando (en aplicaciones de ASP.NET MVC): para crear "Singleton" para DataContext como:

partial class db 
{ 
    static db _db = new db(global::data.Properties.Settings.Default.nanocrmConnectionString, new AttributeMappingSource()); 

    public static db GetInstance() 
    { 
     return _db; 
    } 
} 

o para recuperar nueva instancia cuando que necesitaba dentro using:

using (db _db = new db()) 
{ 
    ... 
} 

el uso de using trae algunas limitaciones en código. entonces prefiero usar singleton one. ¿Es una práctica extraña?

UPD:
explicación de por qué estoy usando Singleton:

public class UserGroupRepository 
{ 
    public static IQueryable<Group> RolesFor(string username) 
    { 
     User user = UserRepository.WithUsername(username); 

     return from g in db.GetInstance().Groups 
       join ug in db.GetInstance().UsersGroups on g.Id equals ug.GroupId 
       where ug.UserId == user.Id 
       select g; 
    } 
} 

tengo este método. debido a que devuelve IQueryable - Puedo continuar compilando la consulta sin que se ejecute, por lo que aquí solo devuelve el resultado diferido.
si reescribo el mismo código con using - no puedo devolver IQueryable (porque db se eliminará e IQueryable también se perderá), y lo cambiaría a List. y ahora este método devolverá una "enorme" lista desde la cual filtraré los datos en la función anterior.

espero que describa lo suficientemente detallado.

Answer 1

Los contextos de datos de Lqq a Sql NO son seguros para subprocesos y solo se deben usar en el contexto de un solo hilo. El uso del patrón singleton no solo es contrario a las prácticas estándar de linq2sql, sino que generará serios problemas si su aplicación se ve afectada por algún tipo de carga grave.

EDIT:

En respuesta a sus limitaciones en cuanto a la usando el bloque, intente poner en práctica el método de RolesFor como un método de extensión:

public static IQueryable<Group> GetUserRoles(this Database db, string username) 
{ 
     return from g in db.GetInstance().Groups 
       join ug in db.GetInstance().UsersGroups on g.Id equals ug.GroupId 
       where ug.UserId == user.Id 
       select g; 
} 

Esto permitiría que llame a su método en el interior un bloque usando desde cualquier lugar:

using(Database db = createContext()) 
{ 
    IQueryable<Group> queryable = db.GetUserRoles("MyUsername"); 
    // from here on you can query the queryable object 
    var groups = (from g in queryable 
        where g.Name == "MyRole" 
        select g).ToList(); 
} 

EDIT 2

En respuesta a su comentario sobre la apertura de otra conexión al servidor sql para cada instancia del contexto de datos. La creación de un contexto de datos no abrirá una conexión al servidor sql, pero sí lo hará cada operación real. Independientemente de si crea 1 o 4 datacontexts, si está realizando 4 operaciones en la base de datos, se abrirán 4 sqlconnections. Sin embargo, tenga en cuenta que .NET utiliza un grupo de conexiones de servidor sql, por lo que cada operación no requiere la creación de una SqlConnection completamente nueva, sino solo la recuperación de una existente del grupo de conexiones y la reapertura de la conexión

Answer 2

Es probable que desee administrar la vida útil de su contexto para tener un alcance a una sola solicitud web y tener solo un contexto para la duración de ese ciclo de solicitud web.

Google busca 'web scoped objectcontext' o 'objectcontext lifetime' (o datacontext for l2s).

p. Ej.http://dotnetslackers.com/articles/ado_net/Managing-Entity-Framework-ObjectContext-lifespan-and-scope-in-n-layered-ASP-NET-applications.aspx

En MVC2 puede poner el código de gestión de contexto en su clase de controlador base.

Answer 3

Linq to SQL quiere que cree un contexto por operación. De hecho, las Opciones de carga de datos solo se pueden configurar para ejecutar la primera consulta, por lo que si desea hacer sugerencias de carga, debe hacerlo de esa manera. Sin embargo, cuando tiene una arquitectura de 3 niveles, se encontrará con el problema de que los objetos de un contexto de datos realmente no pueden trabajar con objetos de un contexto diferente.

Trabajar alrededor de eso es un verdadero dolor, así que simplemente hicimos un contexto por solicitud de material web y un enfoque local de subprocesos para servicios de Windows y similares.