ViewModel constructors

Question

I am having another go at a WPF application incorporating Prism & MEF and attempting to gain a better understanding of the MVVM pattern. I have done this before and, although I have a working solution that I am happy with, I am not convinced that I stayed true to the MVVM pattern in that I ended up with view models exposing a lot of event handlers and the code behind on the views handling these events. These events were aimed primarily at opening additional views (such as edit dialogs) based upon selections made in the initial view.

So far (this time) I have created a shell application with PRISM, I have some regions and I can create views and add them to those regions. I am also using MEF to modularise the solution as well as automatically provide the view models to the views through IoC. Again, this works - to a point...

My problem is with the creation of some of the view models. So far, I have created models that contain lists from databases. These work and so far the most code behind I have is and additional constructor with an [ImportingConstructor] attribute that ensures I get the view model. I am happy with this for the moment (but may look at options later on).

My next step is to provide a new view to edit an item in one of the lists (this is basically a classic master list opening an edit dialog). This is where I cannot see the MVVM/MEF way to do things - I cannot find a way to pass a parameter to a view model constructor based upon the currently selected item in the list.

I know I am trying to be a purist here. I also know that there is nothing wrong with code behind. I am however trying to see if the utopian implementation can actually be acheived.

So, how would you go about this...

Given a list, with a selected item, open a new view (InteractionRequest?) with a view model that contains either (a) the actual item selected in the list or (b) at least some kind of reference to it or one of its properties that can be used to retrieve the item again from the data store?

Answer 1

This is not a direct answer to your question, but MEF was not created for IoC, although it seems to take on that role quite a bit. And I think in your case, you need a real IoC container.

What I typically do (using Unity) is either create a child container and register the instance of the class I want to provide to the view model with the child container using a ContainerControlledLifetimeManager (which, in Unity means that the container will always return the same instance when asked). I usually do this when other things 'down the tree' so to speak will need the same class instance.

The other technique is the use of parameter overrides, which instructs unity to "supply this value to a constructor parameter by this name". This SO question here appears to tell you how you might do this with MEF: MEF Constructor Injection

I think you're on the right track, honestly I would look at getting rid of MEF and using a true IoC container.

You're right though, you probably won't be able to get away with a 100% pure MVVM implementation in a real world application. I have a very large WPF application that I work on, and there are certain places where it just doesn't make sense to do MVVM, usually when you get into simple dialogs and "popup windows".

Answer 2

I will try to answer your questions here:

1. To take care of popups/etc in MVVM way - check various Interaction implementations around. Basically, you have Behavior attached to XAML and bound to some service on VM.

2. To take care of additional actions after construction of VM - it is common to use Start() method on VM and call it in your view right after VM construction.

3. To pass parameters between views - PRISM have INavigationAware and you can pass simple query strings between views

So far I found that I can do most of the stuff MVVM way and go to events/etc in custom controls. I also implement lot's of behaviors to stay MVVM