Bonjour,

Jusqu'à présent je n'ai jamais utilisé de pattern pour la partie visuelle d'une application car le besoin ne se faisait pas sentir. Me disant que cela serait une bonne chose de voir ce qu'il existe, j'ai commencé à regarder un peu le pattern MVP (jai lu quelques articles dont celui sur DVP). J'ai mis de côté MVC, MVP étant une version dérivée où le Presenter a plus de "pouvoir" que le Controller car il gère d'une certaine manière la logique inhérente au visuel si j'ai bien suivi. Le jour où je ferais du WPF on verra pour MVVM, mais ce n'est pas pour tout de suite ^^

L'avantage de ce que j'ai pu lire c'est principalement l'indépendance vis à vis de la partie graphique puisque l'on sépare le visuel des traitements qui lui sont propres. Dans mon cas ce sera toujours du client lourd donc cet avantage ne m'apporte rien, sauf cas de figure ou une Form ne va plus et on doit tout revoir. On peut alors casser le visuel sans mettre à mal la logique derrière. Ce cas n'est pas fréquent mais ça pourrait arriver après tout.

L'autre avantage que je vois c'est avec les Form abstraites que l'on pourrait remplacer par une Form simple et différents Presenter. Quelques propriétés booléenne pour savoir si le visuel doit être adapté un peu en fonction du Presenter est le tour est joué. Le cas n'est pas fréquent non plus mais cela peut servir. D'autant plus que le Form abstraites ne sont pas supportées par le designer Visual Studio (on peut bidouiller pour que cela fonctionne mais bon).

Pour finir, ce pattern simplifie les tests unitaires puisque le code est séparé du visuel. Ce n'est pas négligeable après tout.

Même si pour le moment je n'ai pas vraiment d'avantage à utiliser MVP (écrans simples), je commence à me dire que cela peut être une bonne façon de procéder et qu'il faudrait peut être que je me force à le faire. Ne serait-ce que par souci de clarté via la séparation du code (ce serait déjà une bonne chose après tout) mais aussi pour prendre le réflexe et réaliser les tests unitaires avec les Presenter.

Ce long monologue étant fait, avez-vous
  • des conseils sur la mise en place du pattern MVP ?
  • des conseils sur la manière de tester les Presenter ? Il y a une notion de "Mock objects" à priori à ce stade
  • des articles en particulier ?

En terme de standardisation, de ce que j'ai pu voir pour le moment la communication View vers Presenter se fait par événement. Si l'on attend un retour, une propriété sur le Presenter contient le retour en question (cf. événement NextRequested et propriété Astuce sur la première partie de l'article DVP).

Existe-t-il des variantes qui peuvent être utiles dans certains cas ? Par exemple une méthode sur la View que l'on appellera ce qui permettrait d'avoir plusieurs valeurs de retour, une par paramètre. Ou bien pourquoi pas le retour sur la classe d'EventArgs (même si dans ce cas c'est un peu lourd).

Enfin bref, je cherche un peu de tout et aussi des retours sur expérience (parce qu'après la théorie, il y a la pratique après tout) histoire d'aller sur la bonne voie.

Merci aux courageux qui auront tout lu ... et aux autres aussi