Cela fait maintenant un an que je réalise (principalement) du développement WPF, d'abord pour 2 ou 3 projets "direct-poubelle" - vous savez ces mini-projets que l'on prévoit de ne jamais arriver à finir et qui ne sont là que pour faire toutes les gaffes possibles et imaginables - puis pour deux applications LOB. Bien qu'ils ne soient pas finis, ces deux derniers projets ont aboutis à la création d'un certains nombres de règles d'or que nous utilisons (et utiliseront) pour améliorer le développement...
N'ayez pas peur du découpage design/développement
C'est probablement l'un des points les plus difficiles à mettre en place - et un sujet de complainte fréquent sur les blogs parlant de WPF - mais une fois un certain nombres d'idées prises en compte et appliquées, cela va beaucoup mieux... La règle à retenir pour ce point est : "ne faites pas faire au développeur le travail du designer". Dans les règles suivantes, j'utiliserai le terme "fonctionnel" pour désigner les données et la façon de les manipuler, et le terme "présentation" pour tout ce qui est de l'ordre du rendu visuel. Si vous utilisez un modèle de séparation "règles métier" / "affichage", sachez donc que la partie que je nomme "fonctionnelle" correspond au code utilisé dans la "vue" pour appeler les objets métiers et traiter leurs réponses.
- Le développeur doit exposer des propriétés pour toutes les données qu'il souhaite voir afficher. Ce n'est pas à lui de décider de où, ni de comment seront affichées les informations d'un écran.
- Les animations et autres effets graphiques sont du ressort du designer. Oui, même celles que l'on ne peut pas facilement exprimer en XAML ! Il n'est pas logique que le développeur "fonctionnel" se charge de déclencher des animations ou de manipuler directement des objets (panels, listview...) de la partie "présentation". Après tout, lorsqu'un designer fait une animation Flash, il écrit du code ActionScript pour de très nombreuses choses. Le principe est ici le même : il devra probablement mettre les mains dans le cambouis. Bon, bien sûr, ça c'est le concept, mais une bonne solution pour éviter que le code soit saccagé - euh, oui je suis développeur dans l'âme, pourquoi ? - est :
- Si votre équipe est suffisamment grande, d'affecter un développeur à l'équipe design, ou dans le cas d'une petite équipe de faire travailler le développeur au code de présentation après qu'il ait fini le code fontionnel. Ce développeur-designer sera chargé d'écrire tout le code nécessaire aux animations et autres effets graphiques.
- de séparer dans des fichiers sources différents (à l'aide de partial class) la partie fonctionnelle de la partie présentation.
- Le développement d'une fenêtre ou d'une page, demandera probablement plusieurs aller-retour. C'est l'une des choses qu'il ne faut clairement pas oublier : il n'y a que très peu de chance que le designer ne soit pas bloqué par un oubli du développeur et/ou que le développeur ne soit pas amené à ajouter du code (évenements, nouvelles propriétés) à cause du designer.
- Vos développeurs vont devoir oublier une bonne partie de ce qu'ils savent sur l'écriture d'une application.Dans chaque développeur Windows Forms se cache un bidouilleur-né : nous avons été habituées depuis longtemps à nous servir des contrôles directement (qui ne s'est jamais servi de la propriété Tag d'un ListViewItem comme seul et unique conteneur pour ses données métier ?) et donc à nous appuyer sur eux, mais ce genre de comportement ne doit plus être de mise avec WPF.
Prenez le temps de développer un framework applicatif
L'un des points que l'on omet aussi souvent lorsque l'on parle de WPF c'est de se souvenir qu'il s'agit d'un framework de présentation et en tant que tel, qu'il n'est pas suffisant dans le développement d'une application complexe. Qu'il s'agisse de répercussions de ce fait ou des oublis dans le framework, voici deux exemples de fonctionnalités à développer.
- Le modèle de gestion des threads choisi pour le framework est... comment dire ? .... extrêmement pénible ! Pour éviter de nombreux soucis de concurrence, les données utilisées sur celui d'affichage ne sont pas accessibles sur les autres. Il vous faudra donc, pour la santé mentale de vos développeurs, faire développer des classes simplifiant la discussion inter-thread( par exemple pour fusionner le résultat d'un appel asynchrone à un web-service avec une ObservableCollection exposée par votre contrôle)
- Il n'est pas possible d'écrire du code ni même des expressions dans le fichier XAML (il n'y a pas d'équivalent XAML à "IsEnable= (madonne==null)" par exemple), il vous faudra donc créer des classes de conversion de données ou d'extension du markup pour pallier à ce manque.
Acceptez les limites de WPF
Avec .net 3.0 (et 3.5), nous avons le droit à une version 1.0 de WPF, ce qui engendre un certain nombre de soucis et de limitations. Pour un développement réussi, il vous faudra donc les prendre en compte.
- La performance de WPF est loin d'être exceptionnelle... Exit donc les délire d'animations qui demanderont un QuadCore minimum pour fonctionner correctement. Si dans l'ensemble la performance n'est pas mauvaise pour un système vectoriel, certaines fonctionnalités de WPF ne sont clairement utilisable qu'avec parcimonie : les bitmaps effects par exemple sont à réserver à de très petites surfaces
- XAML n'est pas suffisant ! Il est vain d'essayer de faire croire que XAML est une solution parfaite pour les designers. En effet, et malgré une étendue déjà plus qu'impressionnante, certaines choses ne sont pas réalisables en XAML ou ne le sont qu'avec un niveau de complexité bien plus grand qu'en C# (par exemple). N'hesitez donc pas à écrire du code lorsque cela est nécessaire et/ou plus simple !
- Le compilateur XAML a encore du chemin à parcourir. C'est peut-être le point le plus gênant lors de l'utilisation de WPF : il existe de nombreuses erreurs dues à des facteurs techniques (mauvais type d'objet, paramètres incorrects, etc...) qui ne sont pas détectées par le compilateur (alors qu'un compilateur comme celui de C# est capable de les repérer) et qui se traduisent donc par des exceptions plus ou moins compréhensibles (plutôt moins d'ailleurs...) lors de l'exécution. Il n'y a malheureusement pas de palliatif à ce problème mis à part un : prenez votre mal en patience.