Ich finde es viel schwieriger, Ihre Sitzung in einer Desktop-Anwendung zu verwalten, weil Sie einen solchen klaren Bondary wie HttpContext nicht nutzen können. Wie verwalten Sie die Lebensdauer Ihrer Sitzung, um das Lazy Loading zu nutzen, ohne dass eine Sitzung für die gesamte Anwendung geöffnet ist?Was ist Ihre Session-Management-Strategie für NHibernate in Desktop-Anwendungen?
Ich denke es läuft auf das Design Ihrer Objekte hinaus. Da Lazy-Loading auf der Ebene pro Objekt erzwungen werden kann, können Sie diese Tatsache nutzen, wenn Sie über die Sitzungsverwaltung nachdenken.
Zum Beispiel habe ich eine Reihe von Objekten, die datenreich und lazy geladen sind, und ich habe eine Raster/Übersichtsansicht und eine Detailansicht für sie. In der Grid-Übersichtsansicht verwende ich nicht die Lazy-Loaded-Version des Objekts. Ich verwende ein Ersatzobjekt, um diese Daten darzustellen, und dieses Ersatzobjekt ist nicht faul geladen.
Sobald ein Benutzer diesen Datensatz zum Anzeigen/Bearbeiten auswählt und eine mehrseitige Detailansicht des Objekts eingibt, wird das Lazy-Loading auf das spezifische Objekt angewendet. Daten werden jetzt lazy geladen, je nachdem, welche Details nur bei Bedarf angezeigt werden. Auf diese Weise bleibt der Umfang meiner Sitzung, die für das Lazy-Laden geöffnet ist, nur so lange gültig, wie die Detailansicht verwendet wird.
Wie Sie bereits gesagt haben, können Sie nicht die Grenze des HttpRequest verwenden, aber Sie können verstehen, was ein "HttpRequest" in Ihrer Desktop-Anwendung ist.
Lassen Sie mich erklären. Normalerweise ist Ihr HttpRequest ein Controller für eine Aktion und Sie begrenzen Ihre Sitzung auf diese bestimmte Aktion. Jetzt in Ihrer Desktop-Anwendung können die "Controller" (Ereignisse) kleiner sein, aber wie @ Jon sagte, ein Fenster kann leicht eine Grenze darstellen: Sie arbeiten mit den Dingen dort, lassen Sie sie auf Ihrer Sitzung sein.
Vielleicht können wir uns ein Befehlsmuster vorstellen. Jedes signifikante Ereignis wird einen Befehl füttern und auslösen und ihn ausführen. Die Basis-Implementierung von AbstractCommand.Execute() ist verantwortlich für das Initialisieren der Sitzung, das Wrappen der Transaktion, das Aufrufen der konkreten SomeCommand._Execute() - Implementierung und das Schließen aller Elemente.
Wie auch immer, das ist weit davon entfernt, persistent agnostisch zu sein, so wie es sein sollte, wenn ich mein Objekt geladen habe und nur mit einfachen Instanzen arbeiten will (ich beziehe mich hier besonders auf Lazy-Load).
Ist es sonst möglich, eine Art automatisches/automatisches Schließverhalten zu implementieren? Dies sollte erreicht werden, indem die Persistenzschicht für Anforderungen von Abfragen durch höhere Schichten sensibilisiert wird, selbst in den impliziten Fällen wie Lazy-Load-Triggern. Beim Schließen der Verbindung wird die Persistenzschicht möglicherweise nach einer bestimmten Zeitüberschreitung (10 Sekunden) der DB-Inaktivität geschlossen. Ich weiß, das ist nicht scharf. Aber es würde die Persistenz der höheren Schichten wirklich agnostisch machen.
Danke, Marcello
Ayende hat a great article on the subject in MSDN vor kurzem geschrieben.