Question

I took a course on VB.Net + WPF at university last year. For the final project, I decided to give MVVM a go (we hadn’t discussed it at all in the course, I had just researched it and thought it would be a useful exercise). It was a good experience however I’m rather sure I might have made some poor choices when it came to design.

I’ve since graduated and my job has nothing to do with WPF or Windows development however I’m developing a small application in my own time and thought it would be fun to use C# and WPF (C# is a language I very much like to work with and I enjoyed working with WPF so it’s a pretty logical choice).

Anyway, I’m using this as an opportunity to learn more about MVVM and try and implement it in a better way than I did previously. I’ve done a bit more reading and am finding it a lot easier to graph than I had when trying to implement it alongside learning WPF.

I’ve used In The Box MVVM Training as a guide and will be using Unity for dependency injection at this.

Now, in the sample app developed in the guide, there is a single view model (MainWindowViewModel). The MainWindow is pretty much a container with 3 or 4 UserControls which all share the DataContext of the MainWindow.

In my app, I’d like to have a tab-based interface. As such, the MainWindow will be primary concerned with displaying a list of buttons to switch the current view (i.e. move from the ‘add’ view to the ‘list view’). Each view will be a self-contained UserControl which will implement it’s own DataContext.

The same code in the app is as follows:

MainWindow window = container.Resolve<MainWindow>();
window.DataContext = container.Resolve<MainWindowViewModel>();
window.Show();

That’s fine for setting data context of the MainWindow, however how will I handle assigning each user context it’s own ViewModel as a DataContext?

EDIT: To be more specific, when I say tab-based interface, I don’t mean it in the sense of tabs in a text editor or web browser. Rather, each ‘tab’ is a different screen of the application – there is only a single active screen at a time.

Also, while Slauma’s post was somewhat helpful, it didn’t really explain how I’d go about injecting dependencies to those tabs. If the NewStatementView, for example, was required to output it’s data, how would I inject an instance of a class that implements the ‘IStatementWriter’ interface?

EDIT: To simplify my question, I’m basically trying to figure out how to inject a dependency to a class without passing every dependency through the constructor. As a contrived example:
Class A has Class B.
Class B takes as a constructor paramater needs an implementation of Interface I1.
Class B uses Class C.
Class C takes as a constructor paramater needs an implementation of Interface I2.

How would I handle this scenario using DI (and Unity)? What I don’t want to do is:
public class A(I1 i1, I2 i2) { …. }

I could register everything using Unity (i.e. create I2, then C, then I1 and B, and then finally insert these into A) but then I would have to instantiate everything when I want to use A even if I might not even need an instance of B (and what if I had a whole bunch of other classes in the same situation as B?).

Answer 1

MVVM has lots of benefits, but in my experience wiring up the view models and the views is one of the biggest complexities.

There are two main ways to do this:

1:

Wire the view models to the views.

In this scenario, the XAML for the MainWindow contains the child controls. In your case, some of these views would probably be hidden (because you are only showing one screen at a time).

The view models get wired to the views, usually in one of two ways:

In the code behind, after the InitializeComponents() call or in a this.Loaded event handler, let this.DataContext = container.Resolve<MyViewModelType>();

Note that in this case the container needs to be globally available. This is typical in applications that use Unity. You asked how children would resolve interfaces like IStatementWriter. If the container is global, the child view models could simply call container.Resolve<IStatementWriter>();

Another way to wire the view models into the views is to create an instance of the view model in XAML like this:

<UserControl ...>
  <UserControl.DataContext>
    <local:MyViewModelType/>
  </UserControl.DataContext>
  ...
</UserControl>

This method is not compatible with Unity. There are a few MVVM frameworks that allow you to resolve types in XAML (I believe Caliburn does). These frameworks accomplish this through markup extensions.

2:

Wire the view up to the view model.

This is usually my preferred method, although it makes the XAML tree more complicated. This method works very well when you need to perform navigation in the main view model.

Create the child view model objects in the main view model.

public class MainViewModel
{
   public MyViewModelType Model1 { get; private set; }
   public ViewModelType2 Model2 { get; private set; }
   public ViewModelType3 Model3 { get; private set; }

   public MainViewModel()
   {
      // This allows us to use Unity to resolve the view models!
      // We can use a global container or pass it into the constructor of the main view model
      // The dependencies for the child view models could then be resolved in their 
      //    constructors if you don't want to make the container global.
      Model1 = container.Resolve<MyViewModelType>();
      Model2 = container.Resolve<ViewModelType2>();
      Model3 = container.Resolve<ViewModelType3>();

      CurrentViewModel = Model1;
   }

   // You will need to fire property changed notifications here!
   public object CurrentViewModel { get; set; }
}

In the main view, create one or more content controls and set the content(s) to the view models that you want to display.

<Window ...>
   ...
      <ContentControl Content="{Binding CurrentViewModel}">
         <ContentControl.Resources>
            <DataTemplate DataType="{x:Type local:MyViewModelType}">
               <local:MyViewType/>
            </DataTemplate>
            <DataTemplate DataType="{x:Type local:ViewModelType2}">
               <local:ViewType2/>
            </DataTemplate>
            <DataTemplate DataType="{x:Type local:ViewModelType3}">
               <local:ViewType3/>
            </DataTemplate>
         </ContentControl.Resources>
      </ContentControl>
   ...
</Window>

Notice that we tie the child views to the view models through data templates on the ContentControl. These data templates could have been defined at the Window level or even the Application level, but I like to put them in context so that it’s easier to see how the views are getting tied to the view models. If we only had one type of view model for each ContentControl, we could have used the ContentTemplate property instead of using resources.

EDIT: In this method, the view models can be resolved using dependency injection, but the views are resolved through WPF’s resource resolution mechanism. This is how it works:

When the content for a ContentPresenter (an underlying component in the ContentControl) is set to an object that is NOT a visual (not derived from the Visual class), WPF looks for a data template to display the object. First it uses any explicit data templates set on the host control (like the ContentTemplate property on the ContentControl). Next it searches up the logical tree, examining the resources of each item in the tree for a DataTemplate with the resource key {x:Type local:OBJECT_TYPE}, where OBJECT_TYPE is the data type of the content. Note that in this case, it finds the data templates that we defined locally. When a style, control template, or data template is defined with a target type but not a named key, the type becomes the key. The Window and Application are in the logical tree, so resources/templates defined here would also be found and resolved if they were not located in the resources of the host control.

One final comment. If a data template is not found, WPF calls ToString() on the content object and uses the result as the visual content. If ToString() is not overridden in some meaningful way, the result is a TextBlock containing the content type.
<–

When you update the CurrentViewModel property on the MainViewModel, the content and view in the main view will change automatically as long as you fire the property changed notification on the main view model.

Let me know if I missed something or you need more info.