CODEWITHSUNDEEP
wpfmvvmcastle-windsorioc-containerunit-of-work
Fenyx4
Fenyx4

Reputation: 151

UnitOfWork lifespan in WPF with an IoC Container

My basic setup is a lot like this; http://visualstudiomagazine.com/articles/2011/10/01/wpf-and-inversion-of-control.aspx

An MVVM setup in WPF. I'm injecting a UnitOfWork and a RepositoryFactory into the ViewModel. This has worked great for the dialogs I've written so far... However large portions of our application are inside of dockable windows (think Visual Studio UI). These are open for as long as the application is.

So my thought is to move the unitofwork from being the lifetime of a dialog down to the lifetime of a method call (Button.Click() for example).

But I haven't figured out a good way of doing that which doesn't break some of the benefits I get from using Castle Windsor as an IoC container and/or not following DRY.

This seems pretty good... http://www.codeproject.com/Articles/543810/Dependency-Injection-and-Unit-Of-Work-using-Castle But I worry about the session being wrapped in a semi-singleton and worry that I might be shooting myself in the foot by removing direct access to the UnitOfWork.

Anyone have a good solution for this? Is the above codeproject good and if not what are its flaws?

Upvotes: 13

Views: 2052

Answers (1)

Sergey Vyacheslavovich Brunov
Sergey Vyacheslavovich Brunov

Reputation: 18106

Just introduce Unit Of Work Factory (for example, IUnitOfWorkFactory) interface and use it where appropriate (inject it, etc).

Also, consider making IUnitOfWork interface inherited from IDisposable interface.

Upvotes: 3

Related Questions