LinqToSql statischer DataContext in einer Webanwendung

8

In einer Webanwendung, die ich aufgerufen habe, habe ich den folgenden Code gefunden, um mit dem DataContext beim Umgang mit LinqToSQL umzugehen.

%Vor%

Wenn Sie später darauf verweisen, tun Sie Folgendes:

%Vor%

Ich habe im Zusammenhang mit LinqToSQL nach Best Practices gesucht.

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

Ist dies ein guter Ansatz, um eine Webanwendung zu erstellen?

@ Longhorn213 - Basierend auf dem, was du gesagt hast und je mehr ich in HttpContext gelesen habe, denke ich, dass du recht hast. Aber in der Anwendung, die ich geerbt habe, ist das verwirrend, weil sie am Anfang jeder Methode die Datenbank erneut anfordern, um die Information zu erhalten, dann diese Instanz des Datenkontextes zu modifizieren und Änderungen daran zu übermitteln.

Davon ausgehend sollte diese Methode nicht empfohlen werden, weil sie den falschen Eindruck erweckt, dass der Datenkontext statisch ist und zwischen den Anforderungen bestehen bleibt. Wenn ein zukünftiger Entwickler denkt, dass die Daten zu Beginn einer Methode erneut angefragt werden, weil sie denken, dass sie bereits da ist, könnten sie Probleme bekommen und nicht verstehen warum.

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

    
SBurris 02.06.2009, 17:43
quelle

5 Antworten

6

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 die über eine statische Eigenschaft zugegriffen wird.

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

    
John Saunders 02.06.2009, 17:45
quelle
0

A DataContext ist billig zu machen und Sie werden nicht viel gewinnen, wenn Sie es auf diese Weise speichern.

    
Andrew Hare 02.06.2009 17:44
quelle
0

Ich habe viele Linq zu Sql Web Apps 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, und in diesem Fall wird das nicht der Fall sein.

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

Sie müssen mit dem Datenkontext in einer nicht verbundenen Umgebung wie einer Webanwendung etwas mehr arbeiten. Es ist am schwierigsten mit einem Update, aber nicht wirklich so schlimm. Ich würde nicht zwischenspeichern und es einfach neu erstellen.

    
David Basarab 02.06.2009 17:46
quelle
0

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

    
yieldvs 02.06.2009 17:52
quelle
0

Ich bevorzuge es, eine Seitenbasisklasse zu erstellen (von System.Web.UI.Page zu erben) 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 funktioniert, es ist eine gute Balance IMHO. Sie können DataContext.SubmitChanges () einfach am Ende der Seite aufrufen und sicher sein, dass alles aktualisiert ist. Sie stellen außerdem sicher, dass alle Änderungen jeweils für einen Benutzer gelten.

Wenn Sie dies über die statische Methode tun, wird das sehr schmerzhaft sein - ich fürchte, DataContext wird die Änderungen im Auge behalten, da es versucht, Änderungen für viele Benutzer gleichzeitig zu verfolgen. Ich glaube nicht, dass es dafür entwickelt wurde.

    
Matt Sherman 02.06.2009 22:22
quelle