MVVM and View/ViewModel hierarchy

Question

I'm working on making my first game using C# and XAML for Windows 8. I'm still learning the core concepts and best practices, and MVVM has been a hurdle. I'll attempt to ask the question in two parts.

Background

The game I'm making is Sudoku. Sudoku has a board that contains a 9x9 grid of tiles. I have three models - Game, Board, and Tile. When a Game is created, it automatically creates a Board, and when the Board is created, it creates 81 (9x9) Tiles.

1. With a hierarchy of views, how are corresponding view models created?

To match the hierarchy of models, I would like to have a hierarchy of views (GameView contains a BoardView which contains 81 TileViews). In XAML, it's pretty easy to create this hierarchy of views with user controls, but I don't understand how the view models get created.

In the examples I've seen, the data context of a user control is often set to the view model (using the ViewModelLocator as a source) which creates a fresh instance of the view model. This seems to work well if you have a flat view, but also seems like it gets messy when you have a hierarchy. Does the GameView create a GameViewModel and leave it up to its BoardView child to create a BoardViewModel? If so, how does the GameViewModel communicate with the BoardViewModel? Can the BoardViewModel communicate back up the hierarchy to the GameViewModel?

2. How does a view model get model data?

In iOS, I would start by using a service to fetch a Game model that was pre-populated with data. I would then create a GameViewController view controller (which was in charge of creating the view) and pass the Game to it. In MVVM, I see the value in having a view be in charge of creating its own view model (ideally using a ViewModelLocator), but I don't understand how that view model gets the model.

In all of the examples I've found online, the view model uses some service to fetch its own data. But I haven't come across any example that accepts constructor params or params passed from a higher level of navigation. How is this done?

I don't want to use an application resource or some other kind of singleton storage method for my model because, not that I do, but what if I wanted to display multiple puzzles on the screen at once? Each GameView should contain its own Game.

Not only does the GameViewModel need a reference to the Game model, but the BoardViewModel that was created somehow (see question 1) needs a reference to the Board model that belongs to the Game model. The same goes for all the Tiles. How is all this information passed down the chain? Can I do this much heavy lifting entirely within XAML, or am I going to have to do some sort of binding or other initialization in code?

Phew!

I appreciate any advice you can give, even if it's not a full answer. I'm also keen to find any examples of MVVM projects that share similar challenges to my own. Thanks a ton!

Drama

I think you are talking about the nested user controls problem (see catel.catenalogic.com/…). Catel itself is not available for WinRT yet (a beta is though), but you can at least understand how I think it should be done. – Battik

Answer 1

I would start by creating a class to begin the application with. Typically I call that class something like ApplicationViewModel or ShellViewModel, even though technically it can abide by different rules than what I would typically use for a ViewModel

This class gets instantiated at startup, and is the DataContext for the ShellView or ApplicationView

// App.xaml.cs
private void OnStartup(object sender, StartupEventArgs e)
{
    var shellVM = new ShellViewModel(); 
    var shellView = new ShellView();    
    shellView.DataContext = shellVM;  
    shellView.Show(); 
}

This is usually the only place I set a DataContext for a UI component directly. From this point on, your ViewModels are the application. Its important to keep this in mind when working with MVVM. Your Views are simply a user friendly interface that allows users to interact with the ViewModels. They're not actually considered part of the application code.

For example, your ShellViewModel may contain:

• BoardViewModel CurrentBoard
• UserViewModel CurrentUser
• ICommand NewGameCommand
• ICommand ExitCommand

and your ShellView might contain something like this:

<DockPanel>
    <Button Command="{Binding NewGameCommand}" 
            Content="New Game" DockPanel.Dock="Top" />
    <ContentControl Content="{Binding CurrentBoard}" />
</DockPanel>

This will actually render your BoardViewModel object into the UI as the ContentControl.Content. To specify how to draw your BoardViewModel, you can either specify a DataTemplate in ContentControl.ContentTemplate, or use implicit DataTemplates.

An implicit DataTemplate is simply a DataTemplate for a class that doesn't have an x:Key associated with it. WPF will use this template anytime it encounters an object of the specified class in the UI.

So using

<Window.Resources>
    <DataTemplate DataType="{x:Type local:BoardViewModel}">
        <local:BoardView />
    </DataTemplate>
</Window.Resources>

will mean that instead of drawing

<ContentControl>
    BoardViewModel
</ContentControl>

it will draw

<ContentControl>
    <local:BoardView />
</ContentControl>

Now the BoardView could contain something like

<ItemsControl ItemsSource="{Binding Squares}">
    <ItemsControl.ItemTemplate>
        <ItemsPanelTemplate>
            <UniformGrid Rows="3" Columns="3" />
        </ItemsPanelTemplate>
    <ItemsControl.ItemTemplate>
</ItemsControl>

and it would draw a board using a 3x3 UniformGrid, with each cell containing the contents of your Squares array. If your BoardViewModel.Squares property happened to be an array of TileModel objects, then each grid cell would contain a TileModel, and you could again use an implicit DataTemplate to tell WPF how to draw each TileModel

Now as for how your ViewModel gets its actual data objects, that's up to you. I prefer to abstract all data access behind a class such as a Repository, and have my ViewModel simply call something like SodokuRepository.GetSavedGame(gameId);. It makes the application easy to test and maintain.

However you get your data, keep in mind that the ViewModel and Models are your application, so they should be responsible for getting data. Don't do that in the View. Personally I like keeping my Model layer for plain objects that hold data only, so only ever perform data access operations from my ViewModels.

For communication between ViewModels, I actually have an article on my blog about that. To summarize, use a messaging system such as Microsoft Prism's EventAggregator or MVVM Light's Messenger. They work like a kind of paging system: any class can subscribe to receive messages of a specific type, and any class can broadcast messages.

For example, your ShellViewModel might subscribe to receive ExitProgram messages and close the application when it hears one, and you can broadcast an ExitProgram message from anywhere in your application.

I suppose another method would be to just attach handlers from one class to another, such as calling CurrentBoardViewModel.ExitCommand += Exit; from the ShellViewModel, but I find that messy and prefer using a messaging system.

Anyways, I hope that answers some of your questions and will point you in the right direction. Goodluck with your project :)

Gangrene

Wow, that's a lot to digest! Let me summarize to see if I've got it: Parent views will contain ContentTemplates with the content attribute set to view model objects. DataTemplates define those ContentTemplates to contain the corresponding views. This means you're not using a ViewModelLocator or IoC, correct? – Drama

Also, the data access still concerns me. If the view model is responsible for fetching its own model, is there a way I can specify additional information about which model to use? If I have hard puzzles and easy puzzles, how do I tell my new GameViewModel which puzzle to use? – Drama

@BrentTraut Personally I don't like using the ViewModelLocator. There are some restrictions with it, such as you can only have one instance of your ViewModel, and not being able to pass it parameters. I prefer to build my application in code, and have the UI simply provide a user-friendly interface for my classes. – Gangrene

@BrentTraut As for your question about data access, that kind of logic I would put in the ViewModel. Either the user selects a puzzle to load (in which case, you'd have an ObservableCollection<GameBoard> AvailablePuzzles and GameBoard SelectedPuzzle in your ViewModel) or you load one based on some other logic in your ViewModel – Gangrene

@Gangrene You choose to build your visual hierarchy in XAML by specifying ViewModels and having DataTemplates replace them with the corresponding View objects (instead of specifying the Views directly and having a ViewModelLocator or another approach at binding the ViewModels). This approach seems to make it more difficult to fine tune the visual layout when multiple views exist in the same window. For example, if you have two views bound to ViewModels of the same class in one window, then using your approach it would be difficult alter one's size without affecting the other. – Eger

@Eger I'm not too sure I understand what you mean. The idea behind it is to have your Views totally separate from your ViewModels. I've always found it very easy to manipulate and maintain the UI layer using this method, as it's completely independent of the data layer. – Gangrene