Meine grundlegende Einrichtung ist sehr ähnlich; http://visualstudiomagazine.com/articles/2011/10/01/wpf-and-inversion-of-control.aspxUnitOfWork-Lebensdauer in WPF mit einem IoC-Container
Ein MVVM-Setup in WPF. Ich injiziere eine UnitOfWork und eine RepositoryFactory in das ViewModel. Das hat für die Dialoge funktioniert, die ich bisher geschrieben habe ... Allerdings sind große Teile unserer Anwendung innerhalb von andockbaren Fenstern (denke Visual Studio-Benutzeroberfläche). Diese sind so lange offen, wie die Anwendung ist.
Also mein Gedanke ist es, die Unitofwork von der Lebensdauer eines Dialogs auf die Lebensdauer eines Methodenaufrufs (Button.Click() zum Beispiel) zu verschieben.
Aber ich habe keinen guten Weg gefunden, dies zu tun, was einige der Vorteile, die ich durch die Nutzung von Castle Windsor als IoC-Container und/oder nicht Folge von DRY habe, nicht bricht.
Das scheint ziemlich gut ... http://www.codeproject.com/Articles/543810/Dependency-Injection-and-Unit-Of-Work-using-Castle Aber ich sorge mich darum, dass die Sitzung in einem Semi-Singleton gewickelt wird und Sorge, dass ich mich in den Fuß schießen könnte, indem ich direkten Zugriff auf die UnitOfWork entferne.
Hat jemand eine gute Lösung dafür? Ist das obige Codeprojekt gut und wenn nicht, was sind seine Fehler?
Hallo Fenyx, ich neige dazu, keine explizite Verwendung von Arbeit zu verwenden, sondern stattdessen direkt ISession (NHibernate) oder DbContext (EF) zu verwenden. Die Lebensdauer für diese ist an die Viewmodels gebunden, selbst wenn sie eine Anwendungslebensdauer haben. Solange diese Ansichten nicht immer mehr Daten aus der Datenbank ansammeln, sehe ich kein Problem. Beachten Sie, dass ein DbContext/ISession nicht mit einer Datenbankverbindung identisch ist. – Marwijn
Ohne zu viel zu reden, lesen Sie diese [Frage] [1]. [1]: http://stackoverflow.com/questions/3653009/entity-framework-and-connection-pooling –
@Sniffer dass 'ist [link caption] (url)';) –