In the previous article, I quickly showed how to create a single-view, single-window WPF application using MVVM Light. The trend in WPF applications is to have a single window holding multiple views so that there are less pop-up dialogs or child windows. This article shows how to construct a simple two view application using MVVM and WPF.
Getting Started
- Requires VS2010
- Ensure that you have Nuget installed
- Manage Nuget Package References and add MVVM Light
- The example code for this article is on github
Note that the XAML, in particular, is elided for brevity and you should go to the git repository for the original code.
Hosting Multiple Views
The application structure is similar to the previous article: we have a MainWindow, a ViewModelLocator, and a MainViewModel.
A picture is worth a thousand words, so without further ado, here is what the project structure looks like in VS2010:
The project is laid out in typical MVVM style: 3 folders for Models, ViewModels, and Views. In this case, we do not have any Models so they can be ignored.
Starting with the Views: we simply have two UserControl XAML files, that contain the views that we want to render. The first view is the one from the previous article. The second is just a text label.
All the work involved in rendering two different views for two different view-models happens in MainViewModel.cs, MainWindow.xaml, and App.xaml.
Looking at the MainWindow XAML, we see the following;
<Window x:Class="TwoViews.MainWindow"
DataContext="{Binding Main,
Source={StaticResource Locator}}">
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="Auto" />
<RowDefinition Height="Auto" />
</Grid.RowDefinitions>
<ContentControl Content="{Binding CurrentViewModel}" />
<DockPanel Grid.Row="1" >
<Button Command="{Binding SecondViewCommand}"
Content="Second View"
DockPanel.Dock="Right" />
<Button Command="{Binding FirstViewCommand}"
Content="First View"
DockPanel.Dock="Left" />
</DockPanel>
</Grid>
</Window>
As before, we use the ViewModelLocator to bind our Main view model to the MainWindow. This time, however, we have a ContentControl that binds to a new property called CurrentViewModel, and two buttons that bind to commands that switch the view models. Even though the buttons are labelled as switching the views, it is actually the view-models that are updated.
The next step in getting this to work is implementing a DataTemplate, per view model that renders a View associated with a ViewModel. We do this in the App.xaml (though we could do it in any Resource section we choose):
<Application x:Class="TwoViews.App"
xmlns:views="clr-namespace:TwoViews.Views"
xmlns:vm="clr-namespace:TwoViews.ViewModels"
StartupUri="MainWindow.xaml"
>
<Application.Resources>
<vm:ViewModelLocator x:Key="Locator" />
<DataTemplate DataType="{x:Type vm:SecondViewModel}">
<views:SecondView />
</DataTemplate>
<DataTemplate DataType="{x:Type vm:FirstViewModel}">
<views:FirstView />
</DataTemplate>
</Application.Resources>
</Application>
For example, this quite literally says ‘if my data type is FirstViewModel, then the WPF framework should render the FirstView UserControl.
So when the Content attribute of our the ContentControl is set to an object of type FirstViewModel, the framework renders the correct View for us.
It should also be noted that because the Content attribute has been set to a particular ViewModel, for example FirstViewModel, it is also set as the DataContext for the view that is rendered, i.e. FirstView, and the data-binding between FirstView and FirstViewModel therefore work.
The last part of the application that wires all of this together is the MainViewModel class. Clearly, we only want a single instance of each view model, so we just declare static instances of each one:
public class MainViewModel : ViewModelBase
{
private ViewModelBase _currentViewModel;
readonly static FirstViewModel _firstViewModel = new FirstViewModel();
readonly static SecondViewModel _secondViewModel = new SecondViewModel();
public ViewModelBase CurrentViewModel
{
get
{
return _currentViewModel;
}
set
{
if (_currentViewModel == value)
return;
_currentViewModel = value;
RaisePropertyChanged("CurrentViewModel");
}
}
public ICommand FirstViewCommand { get; private set; }
public ICommand SecondViewCommand { get; private set; }
public MainViewModel()
{
CurrentViewModel = MainViewModel._firstViewModel;
FirstViewCommand = new RelayCommand(() => ExecuteFirstViewCommand());
SecondViewCommand = new RelayCommand(() => ExecuteSecondViewCommand());
}
private void ExecuteFirstViewCommand()
{
CurrentViewModel = MainViewModel._firstViewModel;
}
private void ExecuteSecondViewCommand()
{
CurrentViewModel = MainViewModel._secondViewModel;
}
}
Note that in the CurrentViewModel property, we also have to RaisePropertyChanged via the INPC interface that ViewModelBase defines. This is so that the data-binding works in WPF, i.e., when we click on the buttons, the view changes: if this line is omitted, you cannot change the views by clicking on the buttons.
If we run the code, we can now see that we can switch between the two views and both views maintain their state (as we are using a static instance of each):
Finishing Off
You might feel that the code above looks repetitive: it is. Many, if not all, MVVM frameworks provided ‘runtime assistance’ in automating this kind of thing. By that, I mean that by naming your classes according to convention, e.g. by always using the ‘View’ and ‘ViewModel’ suffixes, MVVM frameworks heavily use reflection and can associate your views and view-models at run time. Indeed, even the MainViewModel above is often generalized into something that is provided by the MVVM framework.
Footnotes
Previous articles/further reading:
The example code is on github.
