LinqToSql statische Datacontext in einer Web-Anwendung

Question

In einer Web-Anwendung, die ich laufe über habe, fand ich den folgenden Code mit dem Datacontext zu behandeln, wenn sie mit LinqToSQL

public partial class DbDataContext 
    { 
    public static DbDataContext DB 
    { 
     get 
     { 
     if (HttpContext.Current.Items["DB"] == null) 
      HttpContext.Current.Items["DB"] = new DbDataContext(); 
     return (DbDataContext)HttpContext.Current.Items["DB"]; 
     } 
    } 
    } 

Umgang

Dann verweist er dies später zu tun:

DbDataContext.DB.Accounts.Single(a => a.accountId == accountId).guid = newGuid; 
DbDataContext.DB.SubmitChanges(); 

Ich habe im Umgang mit LinqToSQL nach Best Practices gesucht.

Ich bin nicht sicher über den Ansatz, den dieser verwendet, wenn DataContext nicht ThreadSafe ist und eine statische Kopie davon aufbewahrt.

Ist dies ein guter Ansatz für eine Webanwendung?

@ Longhorn213 - Basierend auf dem, was Sie gesagt haben, und je mehr ich in HttpContext gelesen habe, denke ich, dass Sie Recht haben. Aber in der Anwendung, die ich geerbt habe, verwirrte es das, weil sie zu Beginn jeder Methode die Datenbank erneut anfordern, um die Information zu erhalten, dann diese Instanz des Datenkontextes zu modifizieren und Änderungen daran zu übermitteln.

Davon, denke ich, sollte diese Methode entmutigt werden, weil es den falschen Eindruck erweckt, dass der Datenkontext statisch ist und zwischen den Anforderungen persistiert. Wenn ein zukünftiger Entwickler denkt, dass er die Daten zu Beginn einer Methode erneut abfragt, weil sie denken, dass sie bereits da ist, könnten sie Probleme bekommen und nicht verstehen, warum.

Also ich denke, meine Frage ist, sollte diese Methode in der zukünftigen Entwicklung entmutigt werden?

Answer 1

Dies ist keine statische Kopie. Beachten Sie, dass die Eigenschaft es aus Context.Items abruft, das pro Anforderung ist. Dies ist eine Kopie pro Anfrage für den DataContext, auf den über eine statische Eigenschaft zugegriffen wird.

Auf der anderen Seite nimmt diese Eigenschaft nur einen einzigen Thread pro Anfrage an, was möglicherweise nicht für immer gilt.

Answer 2

Ein DataContext ist billig zu machen und Sie werden nicht viel gewinnen, indem Sie es auf diese Weise zwischenspeichern.

Answer 3

Ich habe viele Linq zu Sql Web-Anwendungen gemacht und ich bin mir nicht sicher, ob das, was Sie haben, funktionieren würde.

Der Datenkontext soll die Änderungen verfolgen, die Sie an Ihren Objekten vornehmen. In diesem Fall wird das nicht der Fall sein.

Also, wenn Sie gehen, um Änderungen zu senden, wird es nicht wissen, dass eines Ihrer Objekte aktualisiert, also nicht die Datenbank aktualisieren.

Sie müssen einige zusätzliche Arbeit mit dem Datenkontext in einer getrennten Umgebung wie einer Webanwendung durchführen. Es ist am schwierigsten mit einem Update, aber nicht wirklich so schlimm. Ich würde es nicht zwischenspeichern und neu erstellen.

Answer 4

Auch der Kontext selbst ist nicht transaktional, daher ist es theoretisch möglich, dass ein Update bei einer anderen Anfrage auftritt und Ihr Update fehlschlagen kann.

Answer 5

Ich bevorzuge es, eine Seitenbasisklasse zu erstellen (erben von System.Web.UI.Page), und eine DataContext-Eigenschaft verfügbar zu machen. Es stellt sicher, dass eine Instanz von DataContext pro Seite angefordert wird.

Das hat gut für mich gearbeitet, es ist eine gute Balance IMHO. Sie können DataContext einfach aufrufen.SubmitChanges() am Ende der Seite und versichert sein, dass alles aktualisiert wird. Sie stellen außerdem sicher, dass alle Änderungen jeweils für einen Benutzer gelten.

Wenn Sie dies über statisch tun, wird es schmerzhaft - ich befürchte, dass DataContext die Änderungen aus dem Auge verliert, da es versucht, Änderungen für viele Benutzer gleichzeitig zu verfolgen. Ich denke nicht, dass es dafür entworfen wurde.