Lebensdauer von DataContext / DbContext - Wie lange offen halten?

Nach einigen Experimenten mit dem Context unter dem Entity Framework (mit SQL-Server) konnte ich feststellen, dass Änderungen der Datenbank erst dann bemerkt werden, wenn der Context verworfen und neu erzeugt wird. Das heißt das ETF cacht sozusagen alle geladenen Datensätze (LazyLoading ist aktiviert). Jetzt gab es verschiedene Ideen:

1. Der Context bleibt solange am Leben, wie quasi die Datenbank benötigt wird - im Zweifelsfall solange, wie die Anwendung läuft. Vorteil: Ein Datenzugriff passiert nur dann, wenn Änderungen erfolgen und NICHT bei jedem Anzeigen der Daten. Nachteil: Ich bemerke andere (externe) Änderungen der Daten nicht - könnte das aber z.B. mit einem ChangeNotifier abfangen.

2. Der Context wird für den einmaligen Datenzugriff erzeugt und dann wieder verworfen, bleibt also in meinem Beispiel unter WPF nur für das aktuelle ViewModel aktiv, danach wird er wieder verworfen. Vorteil: Die Daten sind meist aktuell. Nachteil: Ich muss bei jedem Öfnen eines ViewModels alle Daten von der Datenbank erneut laden. Wenn das ViewModel lange offen steht, kann es sein, dass Daten dennoch nicht mehr aktuell sind.

Welche Methode ist die bessere unter der Maßgabe, dass die Anbindung zur Datenbank auch übers Internet oder VPN laufen kann? Oder gibt es ganz andere Gedankenansätze?

Hallo Cannon,

der Context ist im Grunde eine "Unit of Work", also auf deutsch: eine Arbeitseinheit. Somit sollte der Context auch so gehandhabt werden. Was jetzt allerdings eine "Arbeitseinheit" ist hängt sehr von deiner Anwendung ab. Siehe Entity Framework Context Lifetime Best Practices und How to decide on a lifetime for your ObjectContext

Nachteil: Ich muss bei jedem Öfnen eines ViewModels alle Daten von der Datenbank erneut laden.

Nicht unbedingt. Du könntest dir die Daten ja lokal selbst z.B. in einer ObservableCollection<T> halten und nur bei Änderungen an der Collection od. an T die Datenbank atualisieren bzw. wenn du ein neues ViewModel erstellst die Daten aus DB mit jenen in der ObservableCollection<T> abgleichen (mittels Load und !Contains). Aber das hängt auch von deiner Anwendung ab ob das überhaupt sinnvoll ist.

Siehe auch Forumssuche nach unit of work

mfG Gü

Ich arbeite bereits mit UnitOfWork und Repositories.

Auch, wenn ich die Artikel lese, hilft es mir nicht weiter, da sich mir nicht genau der Grund erschließt. Im Falle von WPF geht es darum die UnitOfWork pro ViewModel zu "erneuern". Aber warum? Ist SqlChangeNotifier nicht die bessere Alternative?

SqlChangeNotifier ist nicht die beste Wahl.
Verbindngsabbruch, Last bei vielen Usern....

Besser ist es da bei jedem Eintrag einen Zeitstempel zu erstellen und diesen zu vergleichen.
Jeder meiner Entities hat ein TimestampCreated und TimestampLastUpdated. Wenn ein Submit erfolgt überprüfe ich, ob sich Updated geändert hat und wenn ja send ich ne Warnung raus mit den Optionen den letzten Eintrag anzusehen, zu überschreiben oder zu verwerfen.

Andere Systeme locken eine Entity während einer Bearbeitung, sodass nur einer einen Eintrag bearbeiten kann.
Gibt verschiedene Varianten, je nach Geschmack. Aber das ist keine Besonderheit des EF, sondern gilt quasi für alle Varianten einer DB Verbindung.

@Abt: In diese Fall geht es ja nicht darum Änderungen zu verfolgen, sondern um darüber zu reden, warum die UnitOfWork oder auch der DbContext nur eine "kurze" Lebensdauer haben sollte.

Ich sehe halt einfach die Gefahr, dass ich die Daten ständig vom Server lade, obwohl das unnötig wäre. Auf der anderen Seite sehe ich die Aktualisierung der Datensätze nicht, wenn ich die UnitOfWork auf Dauer behalte und irgendwann ist auch die gesamte Datenbank im Speicher gecacht. 😉

.. weil jede Datenbankverbindung nur solange offen gehalten werden sollte wie nötig.
[Artikel] Ressourcen schonen - Datenbanken richtig öffnen und schließen

Wenn Du Aktualisierungen abonnieren willst dann schalt nen WCF dazwischen.
Der hat ne Connection an die DB und kriegt diese mit und pusht Info an die Clients. Das ist deutlich schonender als Dein Vorhaben.