Après avoir participé à quelques projets WPF depuis maintenant un peu plus d'un an, je suis dans une démarche de rationalisation, car je dois réaliser une présentation technique de retour d'expérience et bonne pratiques pour Microsoft (entre deux ligne de mon dossier VAE qui n'avance toujours pas snif Zip it!).

Du coup, en fouillant parmi les nombreuses ressources intéressantes autour de ce vaaaaste sujet, j'ai voulu allumer la lumière autour des différents patterns qui existent, pour faciliter entre autre les tests unitaires.

Entre le traditionnel pattern MVC (Model Vue Controlleur) (on peut trouver des tonnes d'articles sur le sujet, il date du début de l'ingénierie logicielle http://msdn.microsoft.com/en-us/magazine/cc188690.aspx), et les nouveaux modèles, dur de s'y retrouver.

Chez Microsoft,John Gossman (ici et là) et Dan Crevier (qui en fait une synthèse) ont initié une approche appelée M-V-VM que l'on pourrait résumer ainsi :

  • le Model : les objets métiers, le code, les données, la logique
  • la View :  l'interface utilisateur, la présentation des données. Elle doit etre séparée du modèle.
  • le ViewModel : permet aux deux parties ci-dessus de communiquer.
Bref, honnêtement, le ViewModel, ou Controleur, ou machin ou bidule, on n'en sait plus trop rien... Hmm

Plat de spaghetti

D'un point de vue pragmatique, un article très interessant sur CodeProject de Josh Smith essaie d'etre plus concret dans son explication, et surtout de l'appliquer aux tests unitaires (le sujet d'origine de ma recherche, sisi). Quand à la théorie, on en vient tous à se demander s'il ne faudrait pas mieux appeler ce pattern le M-V-Poo (je vous laisse deviner ce que poo signifie en anglais... ho et puis non tant pis, voilà).

A cela, vous pouvez rajouter l'ancien projet Prism, renommé CAG (non là c'était vraiment pas un jeu de mot volontaire...), à savoir le Composite Application Guidance for WPF disponible chez Patterns and Practices, qui est censé contenir des conseils, design-patterns, exemples et guides, bref le couteau suisse de survie du développeur WPF. Bon ça, c'est la partie secondaire du projet, puisqu'en fait le principal morceau consiste à faire un équivalent de CAB mais pour WPF.

CAG a été implémenté à ma connaissance dans un seul projet d'exemple : le fameux "stock trader", qui est une implémentation de référence disponible sur le site MSDN.

Cela dit, depuis peu un nouveau framework pour WPF est sortit : Caliburn (aucune idée de ce que ca vaut,  quelqu'un pour se prononcer ?)



Bref, vue la jeunesse de tout celà, autant dire que je suis mal barrée pour ma présentation sur les bonnes pratiques : tout est à définir Big Smile


Allez, dernier lien intéressant à lire quand même, en ce qui concerne toujours le sujet initial (les tests, la qualité, tout ça) : windowsclient.net a sortit tout un document axé sur les tests : WPF_Application_Quality_Guide_CTP2_Final guide expliqué ici.


Ouf, voilà, maintenant, on y voit encore moins clair, hein ? :)

Cela dit, pour les longues soirées d'hiver, vous voilà bien équipé au coin de la cheminée.
(Merci à Stéphane Goudeau pour m'avoir aidé à débroussailler les informations)

Edit : Un livre blanc avec un retour d'expérience vient de sortir : Evolving to .Net 3.5 Apps. Il est pas mal, je n'ai pas encore fini de le lire, mais il présente une étude de cas, et toutes les questions en terme d'architecture, que tout nouveau projet se pose.


Elise

NB : En passant, il faut quand même préciser l'importance et l'extrême clarté de l'article suivant : DM-V-VM part 3: A sample DataModel ; si vous voulez un modèle simple d'appel asynchrone aux données sans bloquer la partie UI de votre application WPF grâce au Dispatcher, voici le modèle qu'il vous faut !

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :