Statische Klasse Persistenz in MVC Anwendungen

Question

Ich habe in den letzten paar Monaten mein Webforms Wissen zu MVC Wissen migriert, und ich muss sagen, dass, nachdem ich ursprünglich ein MVC-Skeptiker war, liebe ich MVC und die Art, wie es funktioniert.

Das einzige, was ich noch ein wenig unklar bin, ist, wie statische Klassen in MVC beibehalten werden. In Webforms wurden statische Klassenwerte unter den verschiedenen Clients aufgeteilt, die auf die Anwendung zugreifen. Dies könnte dazu führen, dass ein Benutzer die Werte eines anderen Benutzers überschreibt, sollten Sie statische Klassen verwenden, um benutzerbezogene Variablen zu speichern.

Meine erste Frage ist, ob das bei MVC immer noch so ist oder nicht?

Dann meine zweite Frage ist, wo die DBContext-Instanz in meiner MVC-Anwendung zu halten. Momentan habe ich es als öffentliche Variable in einer statischen DAL-Klasse. Der einzelne Kontext wird dann unter allen Clients aufgeteilt.

Je mehr ich darüber lese, desto mehr fange ich an zu glauben, dass dies der falsche Ansatz ist, aber die Rekonstruktion des Kontexts in jedem Controller scheint sich zu wiederholen.

Gibt es einen Nachteil, den Kontext in einer statischen Klasse zu haben?

Answer 1

Der Kontext sollte kurzlebig sein, also könnte es sich wiederholen, aber ja, schaffen Sie einen Kontext in jedem Controller. Verwenden Sie einen einzelnen Kontext pro Anfrage, um genau zu sein.

Answer 2

Eine einzelne DbContext Instanz über die gesamte Lebensdauer einer Anwendung zu speichern, klingt für mich nicht nach einer guten Idee. Ich verwende normalerweise eine DbContext Instanz pro Request.

Im Folgenden sind zwei Punkte, die Sie vielleicht zu prüfen, während die entsprechende Lebensdauer für DbContext in Ihrer Anwendung entscheiden:

1. Wieder mit dem gleichen Kontext für mehrere Anfragen können Sie von profitieren die Cached Einheiten und Sie könnten viele Treffer in der Datenbank speichern, aber unter könnten Sie dann Leistungsprobleme bekommen, weil Sie irgendwann einmal alle Datenbank-Entitäten im Speicher haben könnten, die sind.

2. Re-instanziierenden Kontext zu oft auf der anderen Seite ist auch nicht empfohlen, weil es eine teure Operation ist.

Sie haben ein ausgewogenes Verhältnis irgendwo zwischen diesen zwei Ansätze zu finden und für mich, DbContextPer Anfrage Instanziieren am besten in den meisten Szenarien funktioniert.

Answer 3

Der DbConext ist nicht threadsicher, EF erlaubt nur einen konkurrierenden Vorgang im selben Kontext. Daher ist es keine gute Idee, es über Anfragen hinweg zu teilen. In den meisten Fällen ist ein Kontext pro Anfrage die beste Lösung. (Hinweis: Es gibt einige IoC-Frameworks wie Autofac, die Instanzen pro Anfrage erstellen können)