linq2sql: Singleton oder verwenden, Best Practices

Question

was ist die bevorzugte Praxis, wenn linq2sql mit (in asp.net MVC-Anwendungen):

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

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

oder abzurufen neue Instanz, wenn: "Singletons" für DataContext wie erstellen es benötigt innerhalb using:

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

die Verwendung von using bringt einige Einschränkungen in den Code. also bevorzuge ich Singleton. ist es eine seltsame Übung?

UPD:
Erklärung, warum ich Singletons bin mit:

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; 
    } 
} 

Ich habe diese Methode. aufgrund der Rückgabe IQQueryable - ich kann weiter komponieren Abfrage ohne es auszuführen, so hier nur faule Ergebnis zurück.
wenn ich den gleichen Code mit using umschreibe - ich kann nicht IQueryable zurückgeben (weil db wird entsorgt und IQueryable wird auch verloren), und ich würde es in Liste ändern. und jetzt wird diese Methode "riesige" Liste zurückgeben, von der ich Daten über die vorherige Funktion filtern werde.

ich hoffe ich beschreibe genug ausführlich.

Answer 1

Linq-zu-Sql-Datenkontexte sind NICHT Thread-sicher und sollten nur im Zusammenhang mit einem einzelnen Thread verwendet werden. Die Verwendung des Singleton-Patterns steht nicht nur im Gegensatz zu den Standardverfahren von linq2sql, sondern führt zu ernsthaften Problemen, wenn Ihre Anwendung ernsthaft belastet wird.

EDIT:

Als Antwort auf Ihre Grenzen im Hinblick auf die Verwendung von Block, versuchen Sie RolesFor Methode als Erweiterung Methode implementieren:

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; 
} 

Dies würde ermöglichen es Ihnen, Ihre Methode innerhalb anrufen ein mit Block von überall:

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

In Erwiderung auf Ihren Kommentar zum Öffnen einer anderen Verbindung zum SQL-Server für jede Instanz des Datenkontextes. Durch das Erstellen eines Datenkontextes wird keine Verbindung zum SQL-Server hergestellt, sondern jede tatsächliche Operation. Unabhängig davon, ob Sie 1 oder 4 Datenkontexte erstellen, werden 4 SQL-Verbindungen geöffnet, wenn Sie 4 Operationen für die Datenbank ausführen. Beachten Sie jedoch, dass .NET einen SQL Server-Verbindungspool verwendet, sodass für jede Operation nicht die Erstellung einer vollständig neuen SqlConnection erforderlich ist, sondern nur das Abrufen einer vorhandenen Verbindung aus dem Verbindungspool und das erneute Öffnen der Verbindung

Answer 2

Wahrscheinlich möchten Sie die Lebensdauer Ihres Kontextes verwalten, damit er auf eine einzelne Webanfrage beschränkt ist und nur einen Kontext für die Lebensdauer dieses Webanforderungszyklus hat.

Google Suche nach 'web scoped objectcontext' oder 'objectcontext lifetime' (oder Datenkontext für l2s).

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

In MVC2 können Sie den Kontextverwaltungscode in Ihre Basiscontroller-Klasse einfügen.

Answer 3

Linq to SQL möchte, dass Sie einen Kontext pro Vorgang erstellen. Tatsächlich können die Datenladeoptionen nur für die Ausführung der ersten Abfrage festgelegt werden. Wenn Sie also Ladehinweise ausführen möchten, müssen Sie dies tun. Wenn Sie jedoch eine 3-Tier-Architektur haben, werden Sie auf das Problem stoßen, dass Objekte aus einem Datenkontext nicht wirklich mit Objekten aus einem anderen Kontext arbeiten können.

Um arbeiten ist das ein echter Schmerz, so haben wir nur einen Kontext pro Anfrage für Web-Stuff und einen Thread lokalen Ansatz für Windows Services und dergleichen.