Lorsqu’on implémente du MVVM, on se retrouve rapidement face à certains scenarios rendant le ViewModel (= DataContext) difficile d’accès. Pas de panique, voyons comment contourner ces quelques difficultés simplement.

Cas simple : DataTemplate

Pour rappel, les contrôles affichant une liste d’éléments (ex.: ListBox, ComboBox, etc.) exposent généralement une propriété ItemTemplate, permettant de modifier l’apparence de chaque élément de la liste. Prenons un exemple simple :

public class MyViewModel
{
    public ObservableCollection<User> Users { get; set; }

    public ICommand ClickCommand { get; set; }
}

<UserControl>
  <UserControl.Resources>
    <local:MyViewModel />
  </UserControl.Resources>

  <Grid x:Name="LayoutRoot">
    <ItemsControl ItemsSource="{Binding Users}">
      <ItemsControl.ItemTemplate>
        <DataTemplate>
           <StackPanel>
             <TextBlock Text="{Binding Prenom}" />
             <Button Content="Clique-moi !"
                     Command="{Binding ClickCommand}" />
           <StackPanel>
        </DateTemplate>
      </ItemsControl.ItemTemplate>
    </ItemsControl>
  </Grid>

</UserControl>

L’ItemsControl va itérer sur chaque élément de Users et produire le visuel déterminé dans l’ItemTemplate. Dans cet exemple, on affiche 2 éléments :

• Un TextBlock bindé sur la propriété Prenom de l’objet courant
• Un button bindé sur une commande

Le soucis provient du DataContext du DataTemplate qui correspond à l’élément sur lequel on itère, et non notre « ViewModel ». Si on traduit le résultat des bindings en bon vieux C#, ça donnerait :

foreach (var user in Users)
{
   TextBlock.Text = user.Name;
   Button.Command = user.ClickCommand;
}

Ce n’est pas exactement ce qu’on veut, étant donné que la propriété ClickCommand provient du ViewModel. Il faudrait en fait changer la source du binding, pour viser le contexte extérieur au DataTemplate.

Heureusement, depuis Silverlight 3, la résolution est plutôt simple. On va simplement changer la source du binding en pointant vers un autre élément de l’UI à l’aide de la propriété ElementName :

<Grid x:Name="LayoutRoot">
  <ItemsControl ItemsSource="{Binding Users}">
    <ItemsControl.ItemTemplate>
      <DataTemplate>
         <StackPanel>
           <TextBlock Text="{Binding Prenom}" />
           <Button Content="Clique-moi !"
                   Command="{Binding DataContext.ClickCommand, ElementName=LayoutRoot}" />
         <StackPanel>
      </DateTemplate>
    </ItemsControl.ItemTemplate>
  </ItemsControl>
</Grid>

Et voilà, par le biais du DataContext du LayoutRoot, on accède à la propriété ClickCommand du ViewModel.

Plus complexe : la DataGrid

Ok, c’était le cas simple. Cette fois, on s’attaque à la DataGrid.

<sdk:DataGrid ItemsSource="{Binding Users}" AutoGenerateColumns="False">
   <sdk:DataGrid.Columns>
     <sdk:DataGridTemplateColumn>
       <sdk:DataGridTemplateColumn.CellTemplate>
          <DataTemplate>
              <ComboBox ItemsSource="{Binding DataContext.Users, ElementName=LayoutRoot}"/>
          </DataTemplate>
       </sdk:DataGridTemplateColumn.CellTemplate>
     </sdk:DataGridTemplateColumn>
   </sdk:DataGrid.Columns>
</sdk:DataGrid>

Allez, varions les plaisirs pour ce nouvel exemple, cette fois on veut accéder à une liste définie dans mon ViewModel, depuis une cellule de DataGrid. Tout fier de moi, j’ai directement appliqué l’astuce de l’ElementName … argh, ça ne fonctionne pas !

Pourquoi tant de haine ? L’ElementName équivaut à un FindName et recherche donc un élément dans l’arborescence visuelle. Or, les DataGridColumns n’existent pas dans l’arborescence visuelle …

L’astuce : le seul moyen de modifier la source du binding est de passer par une ressource. On va s’aider d’une classe intermédiaire qui fera le pont vers le ViewModel :

public class DataContextProxy : DependencyObject
{
    public static readonly DependencyProperty SourceProperty =
        DependencyProperty.Register(
            "Source",
            typeof(object),
            typeof(DataContextProxy),
            new PropertyMetadata(null));

    public object Source
    {
        get { return GetValue(SourceProperty); }
        set { SetValue(SourceProperty, value); }
    }
}

Comment l’utiliser ?

<UserControl>
  <UserControl.Resources>
    <local:DataContextProxy x:Key="DataProxy" Source="{Binding}"/>
  </UserControl.Resources>
  <sdk:DataGrid ItemsSource="{Binding Users}" AutoGenerateColumns="False">
     <sdk:DataGrid.Columns>
        <sdk:DataGridTemplateColumn>
            <sdk:DataGridTemplateColumn.CellTemplate>
               <DataTemplate>
                  <ComboBox ItemsSource="{Binding Source.Users, Source={StaticResource DataProxy}}"/>
               </DataTemplate>
            </sdk:DataGridTemplateColumn.CellTemplate>
        </sdk:DataGridTemplateColumn>
     </sdk:DataGrid.Columns>
  </sdk:DataGrid>
</UserControl>

Par étape :

1. Ajout du DataContextProxy aux ressources courantes, et on notera bien le Source= »{Binding} » signifiant qu’on binde sur le DataContext courant (=ViewModel)
2. Changement de la Source du binding pour pointer sur le proxy : Source={StaticResource DataProxy}
3. Modification du Path : {Binding Path=Source.Users}

Et le tour est joué !

Le roi du binding

Avec ces deux méthodes, vous voilà parés à toutes les situations de binding tortueux du DataContext.