Comment tirer efficacement parti des avantages de WPF tout en gardant une application maintenable et testable ?

La méthodologie Modèle / Vue / Vue-Modèle est une variation du patron de conception MVC, taillée sur mesure pour les technologies modernes d'interface utilisateur où la réalisation de la Vue est davantage confiée à un designer qu'à un développeur classique. Le terme designer désigne ici un artiste davantage concerné par les aspects graphiques et d'expérience utilisateur que par l'écriture de code. Le design en question est réalisé en langage déclaratif (ici XAML) à l'aide d'outils spécialisés (Expression Blend).

Le modèle est tel qu'il est défini dans MVC : il constitue la couche de données métier et n'est lié à aucune représentation graphique précise. Le modèle est réalisé en code C# et ne repose pas sur l'utilisation de technologie propre à WPF. Le Modèle n'a aucune connaissance de l'interface graphique qui lui est associée.

La vue est constituée des éléments graphiques : fenêtre, bouton, sélecteur, etc. Elle prend en charge les raccourcis clavier et ce sont les contrôles eux-mêmes qui gèrent l'interaction avec les périphériques de capture (clavier / souris) alors que c'était la responsabilité du Contrôleur dans MVC. Les contrôles sont rassemblés dans un UserControl, dont le nom est généralement suffixé par « View » (par exemple MasterView.xaml).

Pour l'utilisation et la présentation des données à l'utilisateur, le DataBinding entre en jeu. Dans des cas simples, la Vue peut être directement « bindée » sur le Modèle : par exemple le modèle expose une propriété booléenne qui est bindée sur un CheckBox dans la Vue.

En revanche, pour des cas plus complexes, le Modèle peut ne pas être directement exploitable par la Vue. Cela peut être le cas lors de la réutilisation d'un Modèle déjà existant qui ne présente pas les propriétés attendues par la Vue.

C'est justement la partie Vue-Modèle qui est responsable des tâches énoncées précédemment. Le bloc Vue-Modèle peut être vu comme un adaptateur entre la Vue et Modèle, qui réalise plusieurs tâches :

• adaptation des types issus du Modèle en des types exploitables via le databinding par la Vue ;
• exposition de commandes que la vue utilisera pour interagir avec le Modèle ;
• garde trace de la sélection courante des contrôles.

Les classes Vue-Modèle exposent donc des propriétés qui seront directement exploitables depuis le XAML définissant la Vue. Ces propriétés peuvent n'avoir qu'un accesseur get dans le cas d'un binding OneWay, ou des accesseurs get et set pour un binding TwoWay. Dans les deux cas, l'implémentation de l'interface INotifyPropertyChanged est nécessaire afin de signaler les changements au moteur de binding de WPF.

En règle générale, les classes Vue-Modèle n'ont pas besoin de connaître la Vue qui les exploite. Parfois, il peut être nécessaire de connaître cette information, mais des mécanismes existent pour essayer d'abstraire au maximum les classes Vue-Modèle des Vues associées (avec l'utilisation d'interfaces par exemple).

Les classes Vue-Modèle introduisent donc une abstraction entre la partie graphique (le XAML, réalisé par le designer) et le reste (les classes Vue-Modèle et Modèle réalisées par les développeurs). Le but est d'obtenir une architecture la plus faiblement couplée possible.

En plus des fonctionnalités de WPF qui rendent l'utilisation de la méthodologie complètement naturelle (Databinding, DataTemplate, etc.), les classes Vue-Modèle offrent l'avantage d'être faciles à tester. Puisque les classes Vue-Modèle sont des classes « standard », il devient possible d'écrire des tests unitaires. En quelque sorte, les tests unitaires et la vue (en XAML) deviennent tous deux consommateurs de la classe Vue-Modèle associée.

Le diagramme suivant résume le fonctionnement des différents blocs :

Puisque toutes les classes Vue-Modèle doivent implémenter l'interface INotifyPropertyChanged, ce travail peut n'être fait qu'une fois, en définissant une classe de base dont toutes les classes Vue- Modèle dériveront. J'ai l'habitude pour cela d'écrire une méthode protégée OnPropertyChanged qui attend en argument le nom de la propriété qui a changé, et qui lève l'événement PropertyChanged associé.

De plus, une idée que j'ai reprise sur un article de Josh Smith (2) consiste à vérifier (en mode debug seulement) que la propriété pour laquelle l'événement PropertyChanged est levé existe bien (en utilisant la réflexion). Cela signifie qu'un appel tel que OnPropertyChanged(« Nom ») produira une exception visible au débuggeur sur la propriété Nom n'existe pas. Cette petite astuce permet d'éviter certaines erreurs de binding.

Lorsqu'une Vue est créée, il est nécessaire de créer la classe Vue-Modèle qui lui est associée. Il est possible de réaliser cela de deux manières :

• depuis le code-behind en C#, on instancie la classe Vue-Modèle dans le constructeur et on définit le DataContext de la Vue

public ActionsView() 
{ 
    InitializeComponent(); 
    this.DataContext = new ActionsViewModel(); 
}

• directement depuis le XAML de la Vue, on définit la propriété DataContext

    <UserControl.DataContext> 
        <local:ActionsViewModel/> 
    </UserControl.DataContext>

Les deux méthodes sont complètement équivalentes. À titre personnel, je préfère utiliser la première pour pouvoir éventuellement fournir un argument au constructeur de la classe Vue-Modèle.

Une fois que la classe Vue-Modèle est instanciée et que le DataContext de la Vue est positionné convenablement, il est possible de réaliser des bindings entre la Vue et les propriétés du Vue- Modèle.

Le fait de disposer d'une classe adaptateur entre la Vue et le Modèle peut permettre dans certains cas de se passer de convertisseur (3) (IValueConverter ou IMultiValueConverter). En effet, la classe Vue- Modèle ayant justement le rôle de présenter les données en vue de leur affichage, le travail de conversion peut être effectué ici.

L'utilisation de l'interface INotifyPropertyChanged permet de synchroniser un binding avec une propriété. Dans le cas d'un binding vers une liste d'objets, il faut implémenter l'interface INotifyCollectionChanged. Fort heureusement, WPF fournit sa propre implémentation : c'est la fameuse classe ObservableCollection.

ObservableCollection est une nouvelle classe du framework 3.x. De ce fait, il est tout à fait possible de ne pas souhaiter utiliser cette classe dans le Modèle, ou bien de réutiliser un Modèle antérieur au framework 3.x (qui n'utilise donc pas d'ObservableCollection).

Pour cela, lors de l'initialisation de la classe Vue-Modèle, la liste d'objets gérée par le Modèle est parcourue pour remplir une ObservableCollection. Les événements « élément ajouté » et « élément supprimé » du Modèle sont gérés par la classe Vue-Modèle afin de mettre à jour l'ObservableCollection en conséquence.

WPF introduit la notion de commande au travers de l'interface ICommand. Les implémentations fournies avec WPF de cette interface sont les classes RoutedCommand et RoutedUICommand. Nous allons voir dans cette partie que ces implémentations ne sont pas adaptées à une utilisation avec la méthodologie MVVM. Nous verrons pourquoi et comment utiliser le mécanisme des commandes dans notre cas.

La documentation MSDN associée à cette notion donne l'introduction suivante :
« Contrairement à un simple gestionnaire d'événements joint à un bouton ou une minuterie, les commandes séparent la sémantique et l'appelant d'une action de sa logique. Cela permet à diverses sources d'appeler la même logique de commande et de personnaliser la logique de commande par rapport à différentes cibles. »

Si vous avez déjà utilisé les RoutedCommand, vous avez dû remarquer que leur utilisation dans une application est quelque peu fastidieuse. La commande est définie statiquement dans une classe, et afin d'associer une action à une commande, il faut passer par la collection CommandBindings du contrôle auquel est associée la commande :

this.CommandBindings.Add( 
    new CommandBinding( 
        ApplicationCommands.Find, 
        Find_Execute,  
        Find_CanExecute));

C'est en particulier l'utilisation des CommandBindings (qui imposent d'ajouter du code dans le fichier .xaml.cs) qui n'est pas compatible avec la méthodologie MVVM. Dans notre cas, on aimerait avoir les points suivants :

• définition de la commande dans la classe Vue-Modèle: une commande est un moyen que le développeur offre au designer pour interagir avec le Modèle ;
• gestion des actions Execute/CanExecute dans la classe Vue-Modèle : c'est également la responsabilité du développeur de décider quoi faire quand la commande est exécutée, et quand elle peut l'être.

Cela est possible, en réalisant notre propre implémentation de l'interface ICommand. Vous verrez dans l'application d'exemple comment cela est réalisé, et vous découvrirez à quel point il devient simple et naturel d'utiliser les commandes !

La question ici est de connaître, dans les classes Vue-Modèle, l'état de la sélection courante de l'utilisateur. La « sélection » s'applique ici aux contrôles qui dérivent de la classe Selector, c'est-à-dire aux ComboBox, ListBox et TabControl.

Une approche est d'utiliser la propriété SelectedIndex qui peut répondre à ce besoin. Une autre possibilité beaucoup plus puissante est d'utiliser l'interface ICollectionView. Au travers d'une méthode statique de la classe CollectionViewSource, il est très facile, à partir d'une source de données bindée dans la Vue, d'obtenir l'interface ICollectionView associée.

ICollectionView collectionView = CollectionViewSource.GetDefaultView(this.Collections);

Cette interface permet également d'observer la sélection courante du contrôle associé à la source de données. Pour cela, il est important de définir la propriété IsSynchronizedWithCurrentItem à True. ICollectionView expose en effet une propriété CurrentItem qui, comme son nom l'indique, contient une référence vers l'objet actuellement sélectionné.

Cette fonctionnalité permet notamment de construire des vues maître/détail facilement. Enfin, il est également possible d'utiliser ICollectionView pour réaliser des opérations de tri, de filtrage ou de regroupement (en utilisant simplement les propriétés Sort, Filter et Group).

Cet exemple a été réalisé rapidement, en utilisant Visual Studio 2008 et sans aucun travail sur la partie graphique (je suis personnellement plus développeur que designer !). Étant à court d'idées originales, le principe de l'application est également minimaliste : maintenir une liste de personne (nom, prénom, sexe, âge) et pouvoir éditer cette liste. La fenêtre se présente comme suit :

La partie gauche donne une vue des personnes disponibles dans la liste (3 personnes sont ajoutées automatiquement au démarrage). La sélection d'une personne permet de l'éditer dans la vue détail associée (sur la droite). Des boutons permettent : l'ajout ou la suppression d'une personne, la navigation dans la liste (personne suivante et précédente). Les boutons sont reliés à des commandes ce qui permet de les désactiver automatiquement en fonction du contexte courant de l'application (on ne peut pas exemple pas avoir plus de 5 personnes dans la liste) :

Il est également possible de chercher une personne par son nom ou son prénom (la recherche et sensible à la casse et cherche sur les premières lettres). Le champ de recherche signale un résultat vide par un style particulier :

L'application utilise les principes suivants :

• décomposition de la fenêtre en deux UserControl (MasterView et DetailView) ;
• instanciation des classes Vue-Modèle depuis le constructeur ;
• utilisation de l'interface ICollectionView pour la recherche et la navigation ;
• utilisation d'une classe ViewModelBase comme classe mère de toutes les classes Vue-Modèle ;
• utilisation d'une implémentation de l'interface ICommand permettant la définition des commandes entièrement dans les classes Vue-Modèle.

Les commandes sont exposées sous forme de propriété dans les classes Vue-Modèle et utilisent une implémentation de ICommand nommée RelayCommand. L'utilisation est très simple :

public ICommand AddCommand 
{ 
    get 
    { 
        if (this.addCommand == null) 
            this.addCommand = new RelayCommand(() => this.AddPerson(), () => 
this.CanAddPerson()); 
 
        return this.addCommand; 
    } 
}

Dans l'accesseur get, si la commande n'est pas encore créée, alors on l'instancie. Pour cela, on crée une instance de la classe RelayCommand dont le prototype est le suivant :

public RelayCommand(Action execute, Func<bool> canExecute)

L'utilisation d'expressions Lambda (avec la syntaxe =>) permet de créer facilement les délégués Action et Func<bool> Les fonctions associées sont également assez simples : la méthode CanAddPerson vérifie que le nombre de personnes est inférieur à 5, la méthode Add utilise la méthode AddPerson pour crée le nouvel objet Person et l'englober dans un PersonViewModel.

private bool CanAddPerson() 
{ 
    return this.persons.Count < 5; 
} 
 
private void AddPerson() 
{ 
    Person newPerson = this.db.AddPerson("firstName", "lastName", 25, Gender.Female); 
    this.persons.Add(new PersonViewModel(newPerson)); 
}

Le contrôle de recherche (un TextBox) a sa propriété Text bindée sur la propriété SearchText de la classe Vue-Modèle associée. À chaque set de la propriété, on met à jour la propriété Filter de l'objet ICollectionView :

public string SearchText 
{ 
    set 
    { 
        this.collectionView.Filter = (item) => 
         { 
             if (item as PersonViewModel == null) 
                 return false; 
 
             PersonViewModel personViewModel = (PersonViewModel) item; 
             if (personViewModel.FirstName.Contains(value) || 
                 personViewModel.LastName.Contains(value)) 
                 return true; 
 
             return false; 
         }; 
 
        this.OnPropertyChanged("SearchContainsNoMatch"); 
    } 
}

Le set signale également le changement de la propriété SearchContainsNoMatch qui permet de savoir si la recherche contient des résultats. Cette propriété est utilisée par un style du TextBox afin de changer l'apparence du contrôle quand la recherche est vide :

<TextBox Text="{Binding SearchText, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" Margin="5"> 
  <TextBox.Style> 
    <Style> 
      <Style.Triggers> 
        <DataTrigger Binding="{Binding SearchContainsNoMatch}" Value="True"> 
          <DataTrigger.Setters> 
            <Setter Property="TextBox.Background" Value="#68FF0000"/> 
            <Setter Property="TextBox.ToolTip" Value="No result found"/> 
          </DataTrigger.Setters> 
        </DataTrigger> 
      </Style.Triggers>                         
    </Style> 
  </TextBox.Style> 
</TextBox>

L'implémentation de la suppression d'une personne est minimaliste :

private void RemovePerson() 
{ 
    this.db.RemovePerson(this.SelectedPerson.Person); 
        this.persons.Remove(this.SelectedPerson); 
}

La personne est tout d'abord supprimée de la « database », puis on supprime l'objet Vue-Modèle associé de l'ObservableCollection. Cette méthode pourrait être améliorée avec un retour de la méthode DataBase.RemovePerson pour savoir si la suppression s'est bien effectuée si ce n'est pas le cas, il ne faudrait pas supprimer l'objet Vue-Modèle.

Le diagramme suivant montre la décomposition de l'application entre les classes Modèles, Vue et Vue-Modèle.