1. La première étape de l'apprentissage de WPF, selon Josh Smith (un gourou de WPF), est la suivante : retirez votre cerveau de votre crâne, faites le tourner de 180°, puis remettez-le en place (voir Figure 1).
Figure 1 : Prérequis avant d'apprendre WPF
Il est vrai que pour nous qui connaissons la programmation d'applications clientes "classiques" (type Win32, MFC, ou même Winforms), l'apprentissage de WPF provoque divers types d'émotions qui vont de l'étonnement à l'incompréhension, en passant par l'admiration ou la colère. La programmation WPF est... hmmm... comment dire... différente.
2. La deuxième étape est d'acheter un livre (celui que je préfère est celui d'Adam Nathan, aucun livre correct en français encore), de consulter
la documentation de WPF sur MSDN, et de regarder des articles, tutoriels, vidéos sur CodeProject, sur des blogs, ou sur
www.windowsclient.net. C'est un long processus : WPF est un environnement de programmation tout neuf, et tout est à découvrir ! Il y a tellement de nouveaux concepts à apprendre.
Comptez plusieurs semaines pour cette deuxième étape (pour la première étape, le délai peut être infini).
A l'issue de cette deuxième étape, vous savez comment faire des petits programmes qui mettent en oeuvre deux ou trois fonctionnalités de WPF. Vous savez créer une fenêtre avec un bouton 3D contenant une vidéo. Vous savez comment récupérer des images sur un site Web, et en afficher les miniatures. Vous pouvez même vous mettre rapidement à Silverlight, et porter votre petit bout de code sur le Web. Idéal pour épater vos collègues. Ajoutez en plus : "bah, j'ai fait ça en une soirée".
Mais mais mais... pas question encore de créer une application. A l'issue de cette deuxième étape, les fonctionnalités de WPF, c'est comme les débris de verre cassés chez un vitrier. Un par un il sont clairs, mais tous ensemble, ils sont opaques.
3. La troisième étape - délicate - est de tester chaque fonctionnalité de WPF dont on peut avoir besoin, dans une étude de faisabilité. Pour vérifier si :
- elle fonctionne correctement, comme indiqué dans la documentation
- elle est rapide (ou pas trop lente)
Il existe malheureusement encore des domaines mystérieux et inconnus de WPF. Ou d'autres lieux où il vaut mieux ne pas s'aventurer si l'on veut conserver des performances correctes. Tout ceci n'est écrit nulle part, et si vous ne le vérifiez pas, vous ne le saurez pas.
Oui, WPF est une technologie très jeune et très prometteuse, mais elle a les défauts (bugs) de sa jeunesse.
Un exemple parmi d'autres, les bitmapeffects sont parfois très lents et, par conséquent, souvent inutilisables. Mais dans le SP1 de .NET 3.5 (qui vient de sortir en béta), ces bitmapeffects ont été totalement réécrits pour profiter de l'accélération matérielle de la carte graphique. Ils sont devenus très rapides ! Surprise surprise...
4. La dernière étape est d'apprendre comment créer des application WPF. Imaginez que votre boss/client vous dise : "bon, ce nouveau projet, là, finalement on va le faire en WPF plutôt qu'en C++/MFC (ou Winforms, ou autre)".
Les MFC proposent nativement une architecture d'application document-vue. Elle a le mérite d'exister et de structurer le développement d'application. Avec WPF, s'élabore une structure similaire, l'architecture modèle-vue-machin. Machin ?!
(
Petite parenthèse sur les design patterns, au cas où. Les design patterns (ou shemas ou patrons de conception en français... ah quelle drôle de langue que le français) ont été décris en 1995 dans un livre culte : "Design Patterns - elements of reusable software". Les design patterns sont d'excellents moyens de formaliser des problèmes classiques de conception de logiciels, et d'apporter une solution. Pourquoi réinventer la roue à chaque fois, alors que d'autres architectes logiciels, d'autres programmeurs, se sont déjà cassés les dents neurones sur des problèmes de conception de logiciel ?
Tout ça pour dire que, en 1995, à l'heure de gloire des MFC, on se passait de ces shemas. Mais maintenant il est impensable qu'un programmeurs, codeur, ou architecte logiciel ne se jette pas la tête la première dans ces patterns, avant de commencer quelque logiciel que ce soit.
)
En 2005-2006, avant même la sortie de WPF, deux gars de chez Microsoft, John Gossman et Dan Crevier, se sont posé la question de savoir comment architecturer une application WPF. Ils ont inventé le pattern Model-View-ViewModel, qui est décrit sur le blog de John Gossman ici puis là, ainsi que sur le blog de Dan Crevier. Plus récemment, Josh Smith a écrit une très bonne synthèse sur codeproject. Avec un brin de malice et de réalisme, le Dr WPF appelle ce pattern Model-View-Poo.
En gros, le pattern Model-View-ViewModel (Modèle-Vue-Machin) profite de la possibilité offerte par WPF de séparer facilement le code et les données d'une part, et l'interface utilisateur et l'affichage des données d'autre part. Ce pattern découpe une application en trois parties :
-
le modèle (Model) : les objets métiers, le code, les données, la logique et les algorithmes du programme. Le modèle est totalement indépendant de l'interface utilisateur, et de sa présentation à l'utilisateur.
-
la vue (View) : la présentation à l'utilisateur des données et des résultats des traitements. C'est l'interface utilisateur, et elle contient des fenêtres, des contrôles, ... Elle est complètement séparée du modèle.
-
le machin (ViewModel, ou Poo) : permet aux deux parties ci-dessus de communiquer. Un pont entre les deux mondes que sont le modèle et la vue. Le machin demande par exemple la mise à jour de l'affichage. Ou bien commande le démarrage d'un nouveau calcul, ou la mise à jour de données.
Bien que le machin (poo) qui relie le modèle et la vue ne soit pas toujours parfaitement décrit ni organisé, le but du shema Modèle-Vue-Truc est déviter que vos applications WPF ne ressemblent à ceci :
Pour aller au delà du simple shema modèle-vue-machin, Microsoft met au point une méthodologie de développement d'application WPF, appelée Prism. Une présentation du concept est effectuée par un membre de l'équipe de Prism. Des conseils, stratégies, design-patterns, exemples et guides font partie de ce kit de survie à l'usage des développeurs d'applications WPF. Ou plutôt des architectes WPF. Ces outils sont destinés à faciliter le développement d'applications WPF conséquentes. Prism n'est pas terminé, mais des préversions sont déjà disponibles sur codeplex. Il faut que je regarde ça de plus près.
Prism : méthodologie de développement WPF
On l'aura compris, la connaissance technique de WPF, de ses contrôles, styles, objets, etc, n'est que la première des étapes de l'apprentissage de WPF. Cette étape est bien décrite sur internet avec des tutoriels, des articles, des webcasts, etc. Il existe aussi de nombreux livres techniques (essentiellement en anglais).
Par contre, cela ne suffit pas pour créer et architecturer de vraies applications. Les shemas, les design patterns, les "guides de bonnes pratiques" sur la manière de combiner les éléments de WPF et construire des logiciels commencent à peine à pointer le bout de leur nez. Il reste encore beaucoup à faire dans ce domaine. La jeunesse de WPF (un an !) explique sans doute le manque de maturité dans ce domaine. A titre de comparaison, les MFC proposaient il y a 15 ans (!) une implémentation automatique du shema Document-Vue, avec un assistant qui générait le squelette de l'application selon ce design pattern. Ce shéma document-vue est un ancêtre du Modèle-Vue-Machin de WPF. Mais ce dernier est encore bien flou...
Bref, développer une application WPF, c'est un peu comme partir à la conquête du Far West il y a 150 ans. C'est une aventure.
Mise à jour : John Gossman (qui a géré le développement de Expression Blend en WPF) vient d'écrire un article intéressant sur le sujet : PresentationModel and WPF, dans lequel il écrit : "WPF is still so new that we still don't know all the best practices and techniques..."