Discussion :

[betsprite]

Bonjour,

Je m'intéresse actuellement au patron de conception MVP (Model-View-Presenter) pour rendre indépendant la vue du modèle.

J'ai cherché donc à le mettre en place dans mon application, ce qui m'a amené à la réflexion suivante :

Le but du MVP et de séparer la vue du modèle.
Le Presenter, qui a connaissance du modèle (soit directement, soit par exposition de méthodes par une interface), peut l'utiliser pour ainsi mettre à jour la vue (exposition d'une interface pour la vue également).
Ainsi, si on veut changer de vue, on a rien à changer dans le Presenter à condition que celle-ci respecte bien l'interface qui lui est exposée..

Maintenant, j'ai mis en place ce concept pour mes controls mais quelle visibilité j'ai de ces derniers de ma fenêtre principale ?
En passant par le designer, on observe que les controls sont déclarés en membres privés, ce que je faisais jusqu'à présent même pour les controls que le designer ne gèrent pas.

Mais pourquoi ne pas garder plutôt en membres privés les interfaces desquelles les controls héritent ? Cela permet, en cas de changement de control, de ne pas avoir à venir changer tous les appels de méthodes du control dans le Presenter de la MainWindow par exemple..

Le control serait donc juste instancié dans le Presenter d'où on conserverait son interface..

Qu'en pensez-vous ?

Merci!

[Seth77]

Salut

Pas trop compris

Pour moi l interface ne doit rien exposer de "visuel" ; aucun bouton/control mais plutot des proprietes et des actions

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
interface IView
{
  void UpdateList(Array list);
  object SelectedItem {get; }
  event EventHandler<EventArgs> UpdateList;
}

la vue implementera l interface et utilisera les controls de son choix.

++

[sisqo60]

Bonjour,

Je rejoint Seth77, l'interface qui sert d'abstraction ne doit pas contenir de référence vers des classes UI (composants visuels). Le but est de pouvoir, comme tu dis, de changer la présentation (composants visuels de la vue) sans impacter le modèle. Cela permet également la ré-utilisabilité des modèles, dans le cas où tu souhaites faire une appli (Winforms et/ou WPF) et une appli web. La logique de présentation dépend beaucoup de la technologie utilisée mais les données restent les mêmes.

De mon expérience, beacoup de devs hésitent à coder dans la vue, alors il codent des fonctionnements "UI" dans le modèle. Ce qui couple davantage la vue et son modèle.

Comme dit bien Seth77, le modèle expose uniquement les propriétés, et actions (Commandes, méthodes etc...) nécessaires à la représentation logique (en terme de vue métier) et non la représentation physique des données qui elle est assumée par la vue.

J'espère avoir été clair

Bon dév.

[betsprite]

Merci pour vos réponses

Je suis d'accord avec vous, je n'ai pas du expliquer assez clairement mon problème :p.

1) J'utilise le modèle MVP pour séparer la vue du modèle.
2) Chaque Vue (UserControl) implémente une interface exposée a un presenter (un pour chaque UserControl) pour les mises à jour de la vue.
3) Lorsqu'on veut changer une vue (UserControl), il suffit alors d'implémenter à nouveau l'interface et rien d'autre, le presenter n'ayant connaissance que de l'interface..
4) La mainWindow respecte elle aussi le patron PVM et contient en membres privés tous les userControls.

Maintenant, admettons que dans le presenter associé à la MainWindow, on ait besoin de, par exemple, souscrire à des événements entre userControls. On aurait besoin de :

- Rendre accessible les userControls, membres privés de la vue MainWindow, depuis son presenter qui lui doit gérer par exemple les souscriptions d'événements.

Mais, ne vaut-il pas mieux dans ce presenter passer les interfaces implémentées par les userControls dans lesquelles on aurait déclaré les événements ? Ceci éviterait, en cas de changement d'une vue, de devoir venir changer aussi le presenter de la mainWindow...

J'espère avoir été plus clair :p.

Qu'en pensez-vous ?