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 patternModel-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..."
Depuis
quelques jours, pas mal d'informations filtrent sur Internet à propos de la prochaine
version de Windows. Le nom de code du successeur de Vista est actuellement Windows
7, après avoir été Vienna.
