La mia configurazione di base è molto simile a questa; http://visualstudiomagazine.com/articles/2011/10/01/wpf-and-inversion-of-control.aspxDurata della vita di UnitOfWork in WPF con un contenitore IoC
Un'impostazione MVVM in WPF. Sto iniettando un UnitOfWork e un RepositoryFactory nel ViewModel. Questo ha funzionato benissimo per i dialoghi che ho scritto finora ... Tuttavia grandi porzioni della nostra applicazione sono all'interno di finestre ancorabili (si pensi all'interfaccia utente di Visual Studio). Questi sono aperti fino a quando l'applicazione è.
Quindi il mio pensiero è quello di spostare l'unità di lavoro da essere la durata di una finestra di dialogo fino alla durata di una chiamata di metodo (ad esempio Button.Click()).
Ma non ho trovato un buon modo per fare ciò che non rompe alcuni dei benefici che ho ottenuto usando Castle Windsor come contenitore IoC e/o non seguendo DRY.
Questo sembra piuttosto bene ... http://www.codeproject.com/Articles/543810/Dependency-Injection-and-Unit-Of-Work-using-Castle Ma mi preoccupo per la sessione di essere avvolto in un semi-Singleton e preoccupazione che potrei io stesso essere la zappa sui piedi, eliminando l'accesso diretto al UnitOfWork.
Qualcuno ha una buona soluzione per questo? Il codeprogetto di cui sopra è buono e se non quali sono i suoi difetti?
Ciao Fenyx, tendo a non utilizzare un uso esplicito del lavoro, ma piuttosto uso direttamente ISession (NHibernate) o DbContext (EF). La durata di vita di questi è legata ai modelli viewmodels anche se hanno una durata di applicazione. Finché queste viste non accumulano sempre più dati dal database, non vedo alcun problema. Tenere presente che un DbContext/ISession non è uguale a una connessione al database. – Marwijn
Senza parlare troppo, dai un'occhiata a questa [domanda] [1]. [1]: http://stackoverflow.com/questions/3653009/entity-framework-and-connection-pooling –
@Sniffer che è '[link caption] (url)';) –