Ich habe kürzlich eine WPF-App so überarbeitet, dass sie nicht mehr jede Verwendung des DbContext in einer using -Klausel umschließt (siehe diese Frage ). Stattdessen verwendet meine App nur den gleichen DbContext Singleton.
Das funktioniert gut, bis auf ein kleines Problem. Ich habe eine Routine, die die Datenbank von Grund auf neu erstellt und einige Standarddaten einfügt. Diese Routine verwendet ADO.NET direkt (nicht den DbContext), so dass der DbContext nicht weiß, dass die Datenbank jetzt völlig anders ist.
Gibt es eine Methode, um den DbContext zurückzusetzen, ohne ihn zu entsorgen? Ich würde es gerne vermeiden, wenn möglich, zu entsorgen, weil dadurch mehrere Referenzen auf den ursprünglichen Singleton in der gesamten App zerstört würden.
Ich konnte keine Methode finden, um den globalen DbContext zurückzusetzen. Ich konnte mein Problem jedoch lösen, indem ich eine DbContextLocator in jede Klasse einfüge, die einen DbContext benötigt, anstatt den DbContext selbst zu übergeben.
Mein Ziel war es, einen globalen DbContext beizubehalten, aber zu erlauben, dass er bei Bedarf zurückgesetzt wird (zum Beispiel nach einem Datenbankaufbau oder -import).
Meine Lösung verwendet eine abstrakte Basisklasse und eine konkrete Klasse.
Basisklasse
%Vor%Betonklasse
%Vor%Verwendung
Erhalte den aktuellen DbContext:
%Vor%Setzen Sie den DbContext zurück:
%Vor%Bearbeiten
Basierend auf Shimmys Feedback, habe ich DbContextLocatorBase zu einem Generic gemacht. (Ich implementiere jetzt auch IDisposable .)
Basisklasse
%Vor%Konkrete Klasse (optional, da die Basisklasse nicht mehr abstrakt ist)
%Vor%Es ist im Allgemeinen eine schlechte Idee, einen ObjectContext für die Lebensdauer der Anwendung geöffnet zu lassen.
ObjectContext (oder DbContext in diesem Fall) ist für eine Arbeitseinheit.
Tags und Links entity-framework entity-framework-4.1 entity-framework-4