2010-01-03 4 views
0

J'ai une architecture en couches comme suit;Le modèle dans MVP - Événements

Présentation
service
affaires
données

Si je mets en œuvre MVP pour la présentation je crois comprendre que la couche de service représente le dire « M » modèle, est que je comprends bien? Si c'est le cas de mon interprétation de MVP, le modèle peut déclencher des événements auxquels mes présentateurs souscriraient. Cela signifie-t-il que ma couche de service déclencherait des événements?

MISE À JOUR

Cette question a été vu plusieurs fois, mais n'a pas attiré des commentaires ou des réponses, s'il y a quelque chose de mal à la question s'il vous plaît commentaire que je voudrais obtenir une réponse sur ce. Merci.

Répondre

0

L'idée de base derrière la partie View Presenter d'une conception MVP est que la vue est légère. Une grande partie de la logique que les gens mettent dans le formulaire et les contrôles résident dans le présentateur. Le présentateur est la grande gare centrale de la conception. Récupérer les données, mettre à jour le modèle et déclencher des événements pour que les autres zones de l'application sachent que quelque chose a changé. Le modèle est principalement axé sur le stockage et la récupération des données souhaitées. La question clé dans l'utilisation de la conception MVP est la suivante: que se passe-t-il si j'arrache des formulaires X et les remplace par des formulaires Y? Si vous vous trouvez à apporter des changements radicaux au présentateur pour refléter la nouvelle interface utilisateur, alors il n'est probablement pas une conception MVP propre.

+0

@RS Conley Merci d'avoir répondu. Ce que vous m'avez dit est tout à fait logique. Il semble que je me bloque sur la façon de traiter lorsqu'un présentateur de mise à jour met à jour le modèle de la façon dont ce changement est notifié à d'autres visualiseurs/présentateurs intéressés qui peuvent être actifs, par ex. si j'ai une vue qui affiche une liste de clients qui, lorsqu'on clique deux fois sur un client, permet d'éditer les détails du client, nous disons que le présentateur de l'éditeur du client déclencherait un événement pour diffuser ce client a été mis à jour et d'autres présentateurs réagiraient à cet événement? Est-ce que c'est là qu'un Event Aggregator intervient? – David

+0

Ne pensez pas à la conception en tant que modèle unique avec plusieurs vues de présentateur en suspension. C'est un modèle avec un présentateur avec une vue multiple suspendu au présentateur. Maintenant, en interne, la présentation du présentateur peut avoir différentes classes prenant en charge chaque vue. Le présentateur peut également avoir plusieurs couches internes. Dans mon CAD-CAM, j'ai une série de classes UIxxx qui supportent chaque View. En dessous, une série de bibliothèques n'ont rien à utiliser avec la commande Command Design Pattern. Ci-dessous, c'est ce que j'appelle UIForms qui gère l'ensemble de l'interface utilisateur. –

+0

Chaque classe UIxxx s'enregistre avec les UIForms. Les classes UIxxx utilisent ensuite les différentes commandes pour manipuler le modèle, pour dessiner, et plus important encore pour votre question, elle peut déclencher la commande pour provoquer d'autres Vues à la mise à jour. Les commandes de mise à jour utilisent UIForms qui s'occupe ensuite de la mise à jour. La relation entre UIForms et les classes UIxxx utilise un modèle de conception d'observateur. Ensuite, chaque classe UIxxx met à jour la vue associée à celle-ci. Ayez juste des couches sous-jacentes que tous vos présentateurs actuels enregistrent eux-mêmes. Utilisez cette couche pour gérer les mises à jour. –

Questions connexes