Discussion :

[StormimOn]

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

[Maniak]

He be, un topic sur le MVP après celui sur le MVC :)

j'ai commencé à regarder un peu le pattern MVP (jai lu quelques articles dont celui sur DVP).

Regarde en priorité : ça pour le tour d'horizon général et les origines, suivi de Presentation Model et Passive View pour les deux patterns créés à partir du pattern MVP initial.

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.

Principalement, non. C'est un des avantages potentiels, mais pas obligatoire.

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é.

Pas compris, mais l'adaptation par booléens interposés me fait peur :)

D'autant plus que le Form abstraites ne sont pas supportées par le designer Visual Studio

Pas une grosse perte ça.

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.

Ça, c'est pas que ce n'est pas négligeable, mais plutôt que c'est lui l'avantage principal de la chose. C'est une raison suffisante pour justifier de s'y mettre.

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.

Bonne initiative :)

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 ?

Pour les articles, cf les liens plus haut donc. Si tu veux un point de référence pour discuter du MVP et de ses variantes, c'est probablement le meilleur choix :)

Pour la mise en place et la manière de tester, ça dépend un peu de ce que tu veux faire.

Pour les tests, un moyen simple est que le Presenter reçoive la vue dans son constructeur, sous forme d'une interface. L'interface contient les évènements, propriétés et méthodes dont le Presenter peut avoir besoin, sans plus.

Quand tu fais tes tests unitaires sur un Presenter, tu passes une fausse vue, implémentant la même interface. Tu déclenches manuellement les évènements sur ta fausse vue et tu contrôles ensuite que le Presenter a bien fait son boulot.

Vu qu'il y a aussi probablement besoin d'accéder aux données, même principe, tu passes la ou les interfaces des objets nécessaires dans le constructeur du Presenter. Dans les tests, tu passes aussi de faux objets implémentant ces interfaces (qui se basent sur des collections alimentées à la main plutôt que sur une base de données par exemple).

Tu peux créer ces fausses classes à la main ou utiliser une des librairies de mocking disponibles (ma préference du moment est pour Moq).


Dans l'immédiat, décortique déjà les articles de Fowler pour voir si ça répond à une bonne partie des questions :)

[StormimOn]

He be, un topic sur le MVP après celui sur le MVC

Bein oui ^^

Pas compris, mais l'adaptation par booléens interposés me fait peur

L'idée c'est par exemple un formulaire qui suivant le cas aura des contrôles visibles ou non, ou bien des contrôles en plus, par rapport à celui de base. Actuellement j'ai par exemple un Form de base abstrait et j'en dérive pour faire deux autres Form. Sur les Form dérivés il y a de petites différences visuelles : deux boutons en plus sur l'un, un seul sur l'autre, avec évidemment des actions associées. Après le coup de la propriété bool pour adapter n'est peut être pas idéale. Tu ferais quoi ?

En tout cas je n'ai plus qu'à lire les articles cités et regarder Moq afin de comprendre ce que sont les Mock objects et l'utilité dans les tests unitaires.

Merci

[Maniak]

L'idée c'est par exemple un formulaire qui suivant le cas aura des contrôles visibles ou non, ou bien des contrôles en plus, par rapport à celui de base. Actuellement j'ai par exemple un Form de base abstrait et j'en dérive pour faire deux autres Form. Sur les Form dérivés il y a de petites différences visuelles : deux boutons en plus sur l'un, un seul sur l'autre, avec évidemment des actions associées. Après le coup de la propriété bool pour adapter n'est peut être pas idéale. Tu ferais quoi ?

Bah faut voir en quoi consistent les traitements liés à ces différences de contrôles, mais a priori là comme ça, il y aurait l'option de reproduire la hiérarchie des formulaires du côté des Presenters ou d'injecter une [ame=http://en.wikipedia.org/wiki/Strategy_pattern]stratégie[/ame] différente pour chaque (le nom du lien est censé être 'stratégie' :). Enfin c'est comme d'hab, faut voir au cas par cas et là c'est très flou :)

Mais ce serait toujours mieux d'éviter d'avoir un Presenter global qui doit bouger quand n'importe quel formulaire dérivé bouge, parce que ses traitements spécifiques sont au milieu des traitements communs.

En tout cas je n'ai plus qu'à lire les articles cités et regarder Moq afin de comprendre ce que sont les Mock objects et l'utilité dans les tests unitaires.

Ah, pour ça :
http://xunitpatterns.com/Test%20Double.html
http://martinfowler.com/articles/mocksArentStubs.html

:)

[StormimOn]

Ca fait pas mal de chose à ingurgiter ^^

A priori je partirais plus sur la Passive View, c'est la vision que j'avais de la chose de ce que j'avais pu lire avant ce sujet, et cela reste la vision que j'ai après avoir vu les liens cités. Après il va falloir appliquer tout ça pour que ça rentre. Et ensuite poster pour voir comment gérer certains cas en particulier.

Le mocking semble être très intéressant, à mettre en oeuvre pour bien comprendre aussi. A priori l'idéal serait de faire un mix entre mocking et tests classiques d'états (Assert, ...).

Mais ce serait toujours mieux d'éviter d'avoir un Presenter global qui doit bouger quand n'importe quel formulaire dérivé bouge, parce que ses traitements spécifiques sont au milieu des traitements communs.

Les traitements spécifiques sont totalement indépendants des autres. Je pensais donc faire un Presenter commun et le dériver pour ajouter les traitements spécifiques (comme tu l'as mentionné). Je pense que c'est valide, mais parce que les traitements spécifiques sont indépendants. Après des propriétés CanDoSomething et CanDoSomethingElse, afin de bloquer l'accès à certaines fonctions au niveau visuel.

Et encore merci pour tes réponses

[Maniak]

Ca fait pas mal de chose à ingurgiter ^^

Ah ça, il faut avoir du temps pour lire c'est sûr :)

Le mocking semble être très intéressant, à mettre en oeuvre pour bien comprendre aussi. A priori l'idéal serait de faire un mix entre mocking et tests classiques d'états (Assert, ...).

Tu frôles le grand débat entre :
- les tests d'interaction, qui ajoutent plein d'expectations sur les mocks pour vérifier que l'objet testé les a bien utilisés comme prévu. Ils sont du coup très dépendants de l'implémentation.
- les tests d'état, qui observent l'état des objets après exécution du traitement, sans se préoccuper de la façon précise dont ce traitement est fait. Ils se servent moins de mocks, et souvent uniquement de stubs/fakes pour fournir des données prédéfinies. Ils sont beaucoup moins dépendants de l'implémentation exacte des classes, mais peuvent donner l'impression de moins bien contrôler ce qui est fait (pas un problème en TDD, pas trop non plus si on surveille la couverture des tests via NCover pour repérer si on a oublié des cas)

Perso j'avais commencé plutôt du côté tests d'interaction (avec RhinoMocks), mais ça devenait vite très lourd de devoir modifier plein de tests chaque fois qu'on fait un refactoring qui change un morceau de plomberie sur lequel ils dépendaient. Maintenant je ne fais quasiment plus que des tests d'état. Je suis passé sur Moq parce que sa syntaxe était beaucoup plus light pour créer de faux objets en indiquant les valeurs de retour (RhinoMocks dispose depuis aussi d'une syntaxe similaire, mais il commence à y avoir un peu trop de façons de faire la même chose à force d'accumuler les évolutions depuis le temps).

Les vrais mocks, avec expectations et vérifications, ont leur utilité, mais il faut considérer ça comme l'artillerie lourde dans l'arsenal des objets de test. Quand le code est bien découplé, on peut généralement faire plus simple. Par contre quand le code est une grosse masse gluante qui se traine sur le parquet, c'est bien utile pour pouvoir mettre des tests en place avant de s'attaquer au nettoyage :)