Model-View-Presenter en WinForms
Je suis en train de mettre en œuvre le MVP de la méthode pour la première fois, à l'aide de WinForms.
Je suis en train d'essayer de comprendre la fonction de chaque couche.
Dans mon programme j'ai une interface graphique bouton qui lorsqu'il est cliqué sur s'ouvre un openfiledialog fenêtre.
Donc, à l'aide de MVP, l'interface graphique gère l'événement click du bouton, puis appelle le présentateur.openfile();
Au sein de l'animateur.openfile(), qui devrait ensuite déléguer l'ouverture de ce fichier de la couche du modèle, ou qu'il n'existe pas de données ou de la logique de processus, devrait-il simplement d'agir sur la demande et ouvrir le openfiledialog fenêtre?
Mise à jour: j'ai décidé d'offrir une prime que j'ai besoin de plus d'assistance sur ce point, et de préférence adapté à mes points spécifiques ci-dessous, de sorte que j'ai contexte.
Bon, après lecture sur MVP, j'ai décidé de mettre en œuvre le Passif de la Vue. Effectivement je vais avoir un tas de contrôles sur une Winform qui sera manipulé par un Présentateur et puis les tâches déléguées au Modèle(s). Mes points spécifiques sont ci-dessous:
- Lorsque le winform des charges, il doit obtenir un treeview. Ai-je raison de penser que la vue doit donc faire appel d'une méthode telle que: présentateur.gettree(), ce sera à son tour déléguer au modèle, ce qui permettra d'obtenir les données pour le treeview, de le créer et de le configurer, de retour pour le présentateur, qui à son tour va passer à la vue qui sera alors tout simplement céder à, disons, un panneau?
- Serait-ce le même pour toutes les données de contrôle sur la Winform, comme j'ai aussi un datagridview?
- Mon Application, a un certain nombre de classes du modèle avec la même assemblée. Il prend également en charge une architecture de plugin avec les plugins qui doivent être chargés au démarrage. Serait le point de vue simplement appeler un présentateur de la méthode, qui à son tour appel à une méthode de chargement de plugins et d'afficher les informations dans la vue? Le niveau serait alors de contrôler le plugin références. Serait la vue de contenir des références ou le présentateur?
- Ai-je raison de penser que la vue doit gérer chaque chose à propos de la présentation, de treeview nœud de couleur, à la grille de données de taille, etc?
Je pense qu'ils sont mes principales préoccupations et, si je comprends comment le flux doit être, pour ces je pense que je vais être d'accord.
OriginalL'auteur Darren Young | 2011-01-25
Vous devez vous connecter pour publier un commentaire.
Ceci est mon humble prendre sur le titre de MVP et de vos problèmes spécifiques.
Première, tout ce qu'un utilisateur peut interagir avec, ou tout simplement être montré, est un vue. Les lois, le comportement et les caractéristiques de ce point de vue est décrite par une interface. Cette interface peut être implémentée à l'aide d'un WinForms de l'INTERFACE utilisateur, d'une console de l'INTERFACE utilisateur, une INTERFACE utilisateur web ou même pas de l'INTERFACE utilisateur (généralement lors de l'essai d'un présentateur) - la mise en œuvre concrète n'a tout simplement pas d'importance aussi longtemps que il obéit aux lois de son point de vue de l'interface.
Deuxième, d'un point de vue est toujours contrôlée par un présentateur. Les lois, le comportement et les caractéristiques d'un tel présentateur est également décrite par une interface. Cette interface n'a pas d'intérêt dans le béton en vue de la mise en œuvre tant qu'il obéit aux lois de son point de vue de l'interface.
Troisième, depuis un présentateur de contrôle de son point de vue, afin de minimiser les dépendances il n'y a vraiment pas de gain en ayant le point de vue sachant rien à propos de son présentateur. Il y a un contrat conclu entre le présentateur et la vue, et c'est indiqué par le point de vue de l'interface.
Les implications de Troisième sont:
Pour votre question, le ci-dessus pourrait ressembler à ceci un peu simplifié code:
En plus de ce qui précède, j'ai l'habitude de disposer d'une base
IView
interface où je planque leShow()
et propriétaire de tout ou vue titre que mon point de vue généralement bénéficier.À vos questions:
1. Lorsque le winform des charges, il doit obtenir un treeview. Ai-je raison de penser que la vue doit donc faire appel d'une méthode telle que: présentateur.gettree(), ce sera à son tour déléguer au modèle, ce qui permettra d'obtenir les données pour le treeview, de le créer et de le configurer, de retour pour le présentateur, qui à son tour va passer à la vue qui sera alors tout simplement céder à, disons, un panneau?
2. Serait-ce le même pour toutes les données de contrôle sur la Winform, comme j'ai aussi un datagridview?
3. Mon Application, a un certain nombre de classes du modèle avec la même assemblée. Il prend également en charge une architecture de plugin avec les plugins qui doivent être chargés au démarrage. Serait le point de vue simplement appeler un présentateur de la méthode, qui à son tour appel à une méthode de chargement de plugins et d'afficher les informations dans la vue? Le niveau serait alors de contrôler le plugin références. Serait la vue de contenir des références ou le présentateur?
4. Ai-je raison de penser que la vue doit gérer chaque chose à propos de la présentation, de treeview nœud de couleur, à la grille de données de taille, etc?
Que sur les données de cliqué sur les nœuds?
5. Si quand je clique sur le treenodes, dois-je passer par le nœud spécifique pour le présentateur et puis, de là le présentateur serait de travailler sur ce qui les données dont elle a besoin et vous demande ensuite le modèle pour que les données, avant de le présenter de nouveau à la vue?
Vous dites que d'Avoir un présentateur dans la vue facilite la communication entre la vue et le présentateur, mais j'ai fortement en désaccord. De mon point de vue est ceci: Lorsque la vue connaît le présentateur, puis pour chaque événement d'affichage la vue doit décider de la présentateur méthode est la bonne personne à appeler. C'est "2 points de la complexité", car la vue ne sais pas vraiment qui événement d'affichage correspond à présentateur méthode. Le contrat ne spécifie pas que.
Si, d'un autre côté, la vue n'expose l'événement réel, alors que le présentateur lui-même (qui sait ce qu'il veut faire lorsqu'une vue de l'événement se produit) s'abonne à faire la bonne chose. C'est que "de 1 point de la complexité", qui dans mon livre est deux fois aussi bon que "2 points de la complexité". En règle générale, moins de couplage signifie moins de coûts de maintenance au cours de l'exécution d'un projet.
J'ai trop tendance à utiliser la encapsulé presenter comme expliqué dans ce lien lostechies.com/derekgreer/2008/11/23/... dans lequel la vue est le seul titulaire de l'animateur.
Pour les trois styles de MVP expliqué dans le lien que vous avez fourni, je crois que cette réponse par Johann pourrait être plus étroitement aligné avec le troisième style qui est nommé l'Observation de Presenter Style: "L'avantage de l'Observation Présentateur de style, c'est qu'il dissocie complètement de la connaissance de l'animateur du point de Vue de prise de Vue, moins sensibles aux changements au sein de l'Animateur."
OriginalL'auteur Johann Gerell
Le présentateur, qui contient tous les logique dans la vue, doit répondre à l'être cliqué bouton @JochemKempe dit. En termes pratiques, l'événement click du bouton gestionnaire d'appels
presenter.OpenFile()
. Le présentateur est alors en mesure de déterminer ce qui doit être fait.Si elle décide que l'utilisateur doit sélectionner un fichier, il appels de retour dans la vue (via un point de vue de l'interface) et de laisser la vue, qui contient tous les aspects techniques de l'INTERFACE utilisateur, affichage de la
OpenFileDialog
. C'est une distinction très importante en ce que le présentateur ne doit pas être autorisé à effectuer des opérations liées à la technologie d'INTERFACE utilisateur en cours d'utilisation.Le fichier sélectionné sera ensuite renvoyé à la personne qui poursuit sa logique. Cela peut impliquer quel que soit le modèle ou le service doit gérer le traitement du fichier.
La principale raison de l'utilisation d'un modèle MVP, l'omi est de séparer l'INTERFACE utilisateur de la technologie à partir de la logique de la vue. Ainsi, le présentateur orchestre en toute logique, alors que l'avis de la garde séparée de la logique de l'INTERFACE utilisateur. C'est très agréable à côté pour effet de rendre le présentateur entièrement unité vérifiable.
Mise à jour: depuis le présentateur est l'incarnation de la logique trouvé dans un point de vue spécifique, le view-presenter relation est de l'OMI, un one-to-one relation. Et à toutes fins pratiques, une instance de vue (un Formulaire) interagit avec un présentateur exemple, et un présentateur instance interagit avec une seule instance de vue.
Cela dit, dans mon de la mise en œuvre de MVP avec WinForms le présentateur toujours interagit avec la vue à travers une interface représentant de l'INTERFACE utilisateur des capacités de la vue. Il n'y a pas de limitation sur la vue qui implémente cette interface, donc différentes "widgets" peut implémenter la même interface d'affichage et de réutiliser le présentateur de la classe.
Bon, je ne laisserais jamais le présentateur boîtes de dialogue ouvrir directement, parce que ce serait briser vos tests. Soit de déchargement qui à la vue ou, comme je l'ai fait dans certains scénarios, "FileOpenService" classe de gérer le dialogue interaction. De cette façon, vous pouvez truquer le fichier de l'ouverture des services au cours des tests. Mettre ce code dans un autre service peut vous donner de nice ré-utilisabilité des effets secondaires 🙂
OriginalL'auteur Peter Lillevold
Le présentateur doit agir sur la demande spectacle de fin de l'openfiledialog fenêtre comme vous l'avez suggéré. Puisque aucune donnée n'est requise à partir du modèle le présentateur peut, et doit, le traitement de la demande.
Supposons que vous besoin de données pour créer des entités de votre modèle. Vous pouvez soit passer le ruisseau creux à la couche d'accès où vous avez une méthode pour créer des entités de la rivière, mais je vous suggère de gérer l'analyse du fichier dans votre animateur et l'utilisation d'un constructeur ou une méthode de création par entité dans votre modèle.
D'un point de Vue a un présentateur mais un présentateur peut avoir plusieurs points de vue.
OriginalL'auteur JochemKempe