ViewModel composition is where you have multiple complex view parts that need to bind to their own ViewModel entity. The approach entails constructing a root ViewModel with properties for each child ViewModel. Then the root View is bound to the root View Model and each View (whether displayed or collapsed) is bound to the corresponding property on the root ViewModel.

WARNING: The below code does not compile. It is pseudo-code with the hopes of conveying the ideas not the syntax.

The ViewModel would look like this:

public class RootViewModel 
{
   ChildViewModelA ChildA { get; set; }
   ChildViewModelB ChildB { get; set; }
}

The View would look like this:

<Grid>
   <ChildViewA DataContext="{Binding ChildA}" />
   <ChildViewB DataContext="{Binding ChildB}" />
</Grid>

You could also implement this in away to allow yourself to select an active workspace.

The ViewModel would look like this:

public class RootViewModel 
{
    public List<ViewModel> ChildWorkspaces { get; set; }
    public ViewModel ActiveWorkspace { get; set; }

    public RootViewModel()
    {
        ChildWorkspaces.Add(ChildViewModelA);
        ChildWorkspaces.Add(ChildViewModelB);
    }
}

The View would look like this:

<Grid>
   <Grid.Resources>
      <DataTemplate DataType="ChildViewModelA">
          <ChildViewA />
      </DataTemplate>
      <DataTemplate DataType="ChildViewModelB">
          <ChildViewB />
      </DataTemplate>
   </Grid.Resources>
   <ContentControl Content="{Binding ActiveWorkspace}" />
</Grid>

This will result in the appropriate visual representation being selected implicity based on the type of the actual object stored in ActiveWorkspace.

As you can see the plurality of “ViewModel” can be ambiguous. Often times we find the need to construct multiple sub-entities to structure the ViewModel appropriately. But all ViewModel entities would be somewhere within the root View Model object.

When implementing MVVM in WPF, I prefer to infer what visual element to apply data context implicitly (as illustrated in the later half of this post). In more complex scenarios I prefer to use a DataTemplateSelector to conduct that decisioning. But in super simple cases you can explicitly apply DataContext either imperatively or declaratively.