Silverlight 4 et Blend 4 RC sont à peine sortis que l'on voit déjà tous les bénéfices apportés par ces derniers. Deux nouveautés ont retenues mon attention, l'amélioration du système de liaisons et le modèle de conception MVVM complètement géré dans Silverlight 4 via l'implémentation des commandes. L'objectif de cet article est de vous familiariser avec l'implémentation du modèle de conception MVVM (Modèle, Vue, Vue-Modèle) dans Silverlight 4 et de mettre en valeur les avantages apportés par le système de liaisons.
I - Un mot sur le nouveau système de liaison
Comme vous le savez sans doute, il est désormais possible de créer des liaisons de données entre différentes instances de DependencyObject. Auparavant, il était simplement impossible de créer une liaison de données lorsque vos objets n'héritaient pas de FrameworkElement. Dorénavant, tout ou presque est "bindable" et c'est tant mieux. Nous pouvons donc créer une liaison entre la rotation d'un RenderTransform et la propriété Value d'un Slider. Cet exemple est peut-être utile en matière de design mais pas vraiment pertinent pour un développeur. Nous montrerons donc plus loin les avantages de cette amélioration dans le cadre MVVM.
II - Avant-propos
Sachez tout d'abord qu'il y a de nombreuses interprétations du modèle de conception MVVM, cet article ne reflète que ma propre vision de ce pattern. C'est en partie pour cette raison que le type de projet MVVM "Silverlight MVVM Application" que l'on pouvait générer dans Blend 4 bêta a été renommé Silverlight Databound Application dans la version RC. Cela permet de ne pas figer MVVM à une seule interprétation et en même temps de dépasser le cadre de ce type de développement.
III - Introduction à MVVM
MVVM est un principe de conception et d'organisation qui sépare le développement d'applications RIA en trois catégories : Modèle, Vue et Vue-Modèle. De cette manière, le code et le design d'une application sont totalement découplés et il est plus facile de les faire évoluer. Concrètement le développeur mettra à disposition du designer des appels de méthodes dans Vue-Modèle qui seront très simple à appliquer sur des composants présents dans la vue.
L'avantage direct de cette méthodologie est de libérer le designer de toute contraintes en matière de design. Il ne se contentera pas de modifier l'aspect visuel de contrôles déjà choisis au préalable. Il pourra, au contraire, définir librement le type de contrôles, leur nom, les transitions sans avoir à se préoccuper des détails de l'implémentation.
Nous verrons un exemple concret de ce concept.
1 - Qu'est-ce qu'une vue ?
Pour faire simple une vue correspond à une interface visuelle dédiée aux interactions utilisateurs. Autrement dit, c'est là que vont agir les utilisateurs, celles-ci sont constituées de trois types de choses :
- Un arbre visuel et logique composé d'instances d'UIElement.
- Des transitions et des animations.
- Des comportements logiques permettant, par exemple, de piloter animations et transitions.
2 - Une vue doit-elle contenir de la logique ?
Ici 90% des développeurs disent non. Pour ma part, je pense qu'une vue doit contenir sa propre logique permettant de gérer ses animations et ses transitions. Dans la majorité des cas, ces tâches ne sont pas gérées par la création de code C# mais par l'utilisation de comportements (behaviors). Ainsi, il n'y a nullement besoin de code C# car les comportements répondent pleinement à cette problématique. Toute la difficulté de conception provient souvent du couplage possible existant entre la gestion des données et l'affichage. Les comportements ont également pour but de répondre à cette problématique. Ceux-ci sont donc déterminants lorsque vous concevez en mode MVVM.
3 - Qu'est-ce que le Modèle ?
Pour faire simple, le modèle contient les données, les mets à disposition. Le modèle gère également toute les appels distants ou opérations permettant les opérations CRUD (Create, Read, Update, Delete). Les développeurs utilisent souvent une classe statique afin d'y accéder simplement. Le modèle peut diffuser des événements si besoin pour indiquer l'état de chaque opération. Vous trouverez quelques développeurs qui verront modèle uniquement comme espace de stockage.
4 - Qu'est-ce que Vue-Modèle ?
C'est là le cœur du modèle de conception MVVM. Pour faire simple, Vue-Modèle est une abstraction de la vue d'un point de vue Modèle. Autrement dit, Vue-Modèle gère la liaison entre les données contenues dans le modèle et leur affichage dans la Vue. C'est donc l'intermédiaire entre Vue et Modèle.
On m'a récemment posé la question :
doit-on partir de Vue-Modèle ou doit concevoir d'abord la vue puis Vue-Modèle ?
Il n'y a pas de réponse simple à cette question. Cela dépend avant tout de votre métier et vers quel type de qualité vous souhaitez tirer l'application. Souhaitez-vous obtenir une forte interactivité graphique ou une architecture propre et efficace avec un maximum de performance ? Certains pensent que les deux sont possibles mais là encore il ne faut pas se leurrer, si l'un n'impactait pas l'autre nous n'aurions qu'un seul type de projet nommé Databound Application. Plus le graphisme et les interactions sont contraignantes, plus il est difficile de fournir une architecture propre et performante en conservant les mêmes délais. Toutefois, lors de la conception d'une application, il est vivement conseillé de partir d'un prototype. La vue est ce qu'il y a de plus concret pour votre client et pour vous en tant que développeur. C'est dans la vue que sont susceptibles de s'opérer de grande modification car c'est ce que le client souhaite mettre à disposition des utilisateurs. Ce ne serait pas forcément le discours d'un spécialiste SQL mais le client n'est pas là pour comprendre des schémas de Base de donnée. Dans le cas d'applications très standards comme un lecteur Vidéo, par exemple, il est possible de concevoir Modèle-Vue en premier car les opérations que souhaite réaliser l'utilisateur seront toujours les mêmes (Lecture, Stoppe, Pause, ect...). L'abstraction des commandes est, dans ce cas, très prévisible. Nous reviendrons sur la notion de commandes plus tard.
5 - Vue-Modèle doit-il gérer les animations et les transitions ?
Si l'on reprend la définition de base (Vue-Modèle est une abstraction de la vue d'un point de vue Modèle), Vue-Modèle ne doit pas gérer les animations directement mais notifier la vue par n'importe quel moyen (propre et efficace) afin que celle-ci déclenche transitions et animations. Encore une fois, les comportements vont grandement nous aider dans cette tâche. Toutefois, dans le cas d'animations créées dynamiquement ou dans certaines problématiques, il arrive que l'on soit obliger de gérer les animations dans Vue-Modèle. Il faudra dans ce cas créer une classe de gestion dédiée ou utiliser des propriétés de dépendances attachées. Tant que possible et contrairement à la croyance répandues, les vues contiennent la logique permettant l'affichage des transitions et animations, c'est à ça que sert le code behind du UserControl Vue. Les comportements ne sont rien d'autres que du code logique placés dans l'arbre visuel et logique. Il n'héritent pas de UIElement mais de DependencyObject. Par défaut, le développeur n'a pas à assurer cette gestion, cela est du ressort du designer interactif dans le meilleur des cas. Cela peut toutefois être remis en cause lorsque vous rencontrez certaines problématiques de conception.
6 - Le tout MVVM ?
La grande question, est-ce que vous devez toujours tout concevoir en MVVM ? La réponse est non. Voici mes arguments:
- Si c'était le cas on aurait pas différents types de projets.
- Utiliser un seul modèle de conception est une pratique extrémiste qui ne répond pas toujours aux contraintes de temps imparties.
- Selon la taille de vos projets et vos besoins en matière d'évolution et de changements, il n'est pas forcément utile d'utiliser MVVM car cela peut par certains côtés ajouter une touche de complexité. Par exemple, lorsque vous essaierez de créer des liaisons de données entre des collections d'objet présent dans la vue et des collections contenues dans Vue-Modèle.
- Faire du Full MVVM relève avant tout du dogme, c'est comme si vous ne cuisiniez que des plats italiens. En bref vous passez à côté de la cuisine française, indienne, etc...
- Plus le design et ses contraintes sont importants, plus il sera difficile de normaliser le développement. C'est l'éternel problématique du développement informatique. Le design et le développement représentent deux facettes de la production qui se lancent des défis en permanence. Pour vous en convaincre, essayez de penser le site suivant en MVVM pour toutes les pages :: www.experience159.com
7 - Schéma récapitulatif
Voici un schéma simple reprenant une partie de ce que nous avons exposé :
Après cette brève introduction, nous allons nous plonger dans la conception d'une application complète en MVVM.
IV - Un diaporama MVVM côté Vue
Téléchargez le projet GalleryMVVM_base. Ce projet est créé sur le modèle Silverlight Databound Application.Vous remarquez tout d'abord que MainPage.xaml contient une vue formalisée par un UserControl nommé GalleryView. On peut donc envisager MainPage comme un conteneur d'agencement des vues. Un répertoire contient les UserControl symbolisant la partie Vue, un autre contient les classes correspondant à Vue-Modèle, le dernier contient toutes les classes côté Modèle gérant l'accès aux données (voir Figure ci-dessous).
Dans GalleryView.xaml, tous nos objets sont déjà créés et designés, ce travail peut être réalisé indépendamment du développement côté C#. On considère que le développeur et le designer se sont mis d'accord sur un certain nombre de fonctionnalités listés ci-dessous :
- Afficher / cacher l'objet interactif (bouton par exemple) Image Précédente / Image Suivante
- Charger Image suivante / précédente
- Récupérer l'ImageBrush de la nouvelle et de l'ancienne image chargées (cela permet de créer des transitions)
- Afficher la pagination
- Afficher la description, le titre et l'url de l'image en cours
- Naviguer vers l'état "chargement en cours" ou l'état "chargement terminé"
- Afficher la barre de progression
Le développeur et le designer ont donc élaboré chacun de leur côté une partie du projet. Le design étant finalisé, il nous faut maintenant récupérer l'abstraction Vue-Modèle, nommée GalleryViewModel, comme contexte de données de la vue. Nous reviendrons plus tard au code de GalleryViewModel. Ajoutez l'espace de nom xmlns:local="clr-namespace:GalleryMVVM", au sein du UserControl racine de GalleryView. Nous allons déclarer une nouvelle ressource de type GalleryViewModel comme montré ci-dessous :
Compilez l'application si besoin par un ctrl+maj+b, maintenant que nous avons instancié la Vue-Modèle comme ressource, nous pouvons facilement la définir comme contexte de données de la grille LayoutRoot comme montré ci-dessous.
Cela n'est pas suffisant, le mieux est de créer une liaison de données car cela permet de mettre à jour la Vue quand Vue-Modèle change, et inversement ( avec liaison à deux voies). Nous remplaçons cette expression
par celle-là :
Rendez-vous maintenant dans le panneau Data, conservez LayoutRoot sélectionné et dépliez Data Context. Vous obtenez une liste de propriétés et de commandes correspondant au cahier des charges établi entre développeur et designer (voir ci-dessous).
Du côté de la vue le tour est joué, il suffit de glisser déposer, les propriétés et les commandes sur les objets de l'arbre visuel et logique. Il est également possible de procéder via l'utilisation du menu DataBinding obtenu lorsque vous cliquez sur l'icône carré présente à droite de chaque propriété d'objet.
Vous pouvez faire un simple test en glissant déposant les commandes DisplayNextPicture et DisplayPreviousPicture sur les boutons et établir une liaison entre le remplissage du Rectangle nommé newBitmap et la propriété NewPictureIB de la Vue-Modèle. Comme vous le constater, le diaporama est entièrement designable, autrement dit, le graphiste peut choisir librement le type, l'agencement, le nom des composants ainsi que les états visuels qu'il souhaite activer. Pour glisser déposer les propriétés de la Vue-Modèle en choisissant la propriété ciblée, il suffit d'appuyer sur la touche alt en même temps que le glisser-déposer.
V - Gérer les transitions
Le nouveau système de liaison apporté par Silverlight 4 nous donne pas mal de souplesse lorsque l'on développe un projet en suivant ce modèle de conception. Dans ce mode de conception, on essaie de limiter au maximum le code logique de chaque vue, il est donc assez pratique d'utiliser des comportements au sein de Blend pour gérer les transitions et les animations. Nous allons utiliser le nouveau système de liaison basé applicable à l'ensemble des instances de type DependencyObject pour gérer nos comportements interactifs.
1 - Déclencher les transitions
C'est une des problématiques majeures lorsque l'on évoque MVVM. En premier lieu, Microsoft propose un comportement interactif nommé DataStateBehavior qui facilite cette gestion. Vous pouvez le déposer sur LayoutRoot, celui-ci est capable de déclencher une transition selon la valeur d'une propriété de Vue-Modèle. Dans notre cas, il s'agit de la propriété IsLoaded qui a pour valeur false lorsque la nouvelle image est en cours de chargement, et true lorsque celle-ci est chargée. La figure ci-dessous affiche le paramétrage du comportement.
Concrètement, il suffit de créer une liaison entre la propriété Binding du comportement et la propriété IsLoaded de la Vue-Modèle. Lorsque la valeur attendue est égale à True alors on affiche l'état visuel Completed sinon on affiche l'état visuel Loading. Cela peut sembler étrange de mettre un T majuscule, toutefois la propriété Value est typée Object. Ainsi, bien que IsLoaded soit de type boolean, c'est sa représentation sous forme de chaîne de caractère qui est comparée par appel implicite de la méthode ToString(). Cette méthodologie a pour avantage de laisser au designer le soin de déclencher les transitions simplement.
2 - activer ou désactiver un comportement interactif
Dans Silverlight 3, il n'était pas possible de lier une propriété de comportement, comme IsEnabled à une propriété de la Vue-Modèle. Même si cette dernière implémentait INotifyPropertyChanged, la propriété IsEnabled n'était pas "bindable" car les comportements n'héritaient pas de FrameworkElement mais de DependencyObject. Avec le nouveau systèmes c'est désormais chose possible. Placez deux instances du comportement GotoStateAction sur chacun des deux exemplaires de bouton. Lorsque la souris survolera l'un ou l'autre, nous naviguerons vers l'état visuel RightButtonMouseOver ou LeftButtonMouseOver. Lorsque la souris quittera le survol de l'objet, nous afficherons l'état DefaultMouseLeave. La figure ci-dessous Toutefois correspond au paramétrage du bouton de droite.
Jusque-là nous n'utilisons pas le contexte de données de la Vue-Modèle mais nous allons y remédier. Dans le scénario de base développeur et designer sont partis du principe que l'affichage d'une pagination (par exemple : image 1/6) n'est pas toujours de mise. Ainsi, cette navigation ne sera possible que dans le cas ou l'affichage de la pagination est prévue par Vue-Modèle. C'est le cas lorsque la propriété DisplayPageNumbers (de GalleryViewModel) est à true. il suffit donc d'établir une liaison de données entre IsEnabled du comportement et DisplayPageNumbers. Voici le code XAML correspondant :
Le code est assez simple à comprendre :
- La visibilité du bouton est liée à RightArrowVisibility de GalleryViewModel.
- Le texte, affiché via la propriété Content, est lié à la propriété Paging de GalleryViewModel.
- Très important, toutes les instances héritant du type ButtonBase implémentent, depuis Silverlight 4, le commanding via la propriété Command. Celle-ci permet d'exécuter des commandes (des actions de ViewModel). L'événement Click provoque l'exécution de la commande. Pour tout autre type d'événements que Click, vous pouvez utiliser le comportement nommé InvokeCommandAction.
- Pour finir, les comportements de navigation sont activés ou désactivés par la propriété DisplayPageNumbers de GalleryViewModel.
VI - le Diaporama côté Vue-Model
Concernant Vue-Modèle, le développeur est sur des rails. Le code est standard et les étape sont toujours les mêmes :
- Il est assez pratique de créer une classe de base dont toutes les classes de type Vue-Modèle hériteront. Vous pouvez l'appeler ViewModel ou ViewModelBase.
- Cette classe doit implémenter deux interfaces : INotifyPropertyChanged et IDataErrorInfo. INotifyPropertyChanged permet de notifier la vue de tout changement de propriété. Cela permet d'utiliser le mécanisme de créer des liaisons de données qui seront rafraichies lorsque les propriétés de Vue-Modèle seront mise à jour. IDataErrorInfo est une nouvelle interface fournie par Microsoft qui permet aux vues d'afficher les erreurs levées lors d'une mauvaise affectation. Concrètement, cela est particulièrement utile lors de liaisons de données à deux voies. Dans notre cas, l'intérêt est moindre car la vue n'a pas de raison de modifier les propriétés de Vue-Modèle. Dans le cas d'un formulaire IDataErrorInfo est obligatoire car bien plus pratique à utiliser qu'une levée d'exception (via l'instruction Throw new Exception). Je vous renvoie à l'article de John Papa concernant l'implémentation de IDataErrorInfo.
- Il est nécessaire de créer des propriétés qui seront accessibles directement depuis la vue
- Pour finir, nous devons créer des commandes qui seront exécutées depuis la Vue. L'implémentation des commandes est également couvert par un article de John Papa que vous trouverez ici. Concrètement, il propose de créer une classe abstraite nommée DelegateCommand qui facilitera l'instanciation de ces dernières dans Vue-Modèle. Normalement, une commande correspond à un type d'objet mais cela peut-être éviter grâce à la délégation.
1 - Les propriétés accessible au sein de la vue "Bindable"
Pour qu'une propriété soit accessible depuis la vue, elle doit utiliser l'accesseur public. De plus, dans l'optique où celle-ci utilise le système de liaison classique, elle doit notifier la vue lorsque qu'elle est modifiée. Pour cela, il suffit d'utiliser la méthode NotifyPropertyChanged héritée de la classe ViewModel, implémentant INotifyPropertyChanged. Voici un exemple pour la propriété exemple
2 - les commandes
Les commandes doivent toujours faire référence à une méthode ainsi qu'à une valeur booléenne qui indique si la commande doit-être exécutée. Voici le code C# correspondant aux commandes DisplayNextPicture et DisplayPreviousPicture :
Rien de bien compliqué, la propriété Index est affectée d'une nouvelle valeur, et notifie la vue de ce changement via le mécanisme héritée de INotifyPropertyChanged. La méthode CanDisplayPictures renvoie systématiquement true ce qui n'est pas l'idéal, vous pourrez faire certains tests à ce niveau. C'est ce que je fais pour la commande LoadAllPicture qui prend en deuxième paramètre de son constructeur le booléen renvoyé par CanLoadAllPictures :
VII - l'application finale
Elle est visible à cette adresse : http://www.tweened.org/wp-content/uploads/applis/diaporamaMVVM/.
Le projet ainsi que les sources complètes sont quant à eux téléchargeables ici : http://www.tweened.org/wp-content/uploads/applis/GalleryMVVM.zip.
Du coup, le designer est complètement autonomes. Au final, ce procédé n'est pas très orthodoxe mais il est très utile. Le principe ne repose sur rien d'autre qu'une compilation conditionnelle générée au niveau du projet(.csproj). Le code suivant :
