MVVM and View/ViewModel hierarchy

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.csprivate 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 :)