Lors de la recherche au-delà de la SAR (glisser-déposer et la configurer) manière de construire des Interfaces Utilisateur de nombreux outils vous encourageons sont susceptibles de croiser 2 modèles de conception appelé Modèle-Vue-Contrôleur et Model-View-Presenter. Ma question comporte trois parties:
En MVP, le Présentateur contient l'INTERFACE utilisateur de la logique métier pour la Vue. Toutes les invocations de la Vue déléguer directement à l'intention du Présentateur. Le Présentateur est également découplé directement à partir de la Vue et des entretiens à travers une interface. C'est pour permettre de se moquant de la Vue dans un test unitaire. Un attribut commun de MVP est qu'il y a beaucoup de deux voies de distribution. Par exemple, lorsque quelqu'un clique sur le bouton "Enregistrer", le gestionnaire d'événement délégués pour le Présentateur de "OnSave" la méthode. Une fois que la sauvegarde est terminée, le Présentateur va ensuite revenir à l'Affichage par le biais de son interface, de sorte que la Vue peut afficher que la sauvegarde est terminée.
MVP a tendance à être un moyen très naturel de modèle pour la réalisation d'une présentation séparée dans les Formulaires Web. La raison en est que la Vue est toujours d'abord créé par le ASP.NET moment de l'exécution. Vous pouvez en savoir plus sur les deux variantes.
Passive Vue: Le point de Vue est aussi stupide que possible et ne contient presque zéro logique. Le Présentateur est un homme du milieu qui parle à la Vue et le Modèle. La Vue et le Modèle sont complètement à l'abri de l'un à l'autre. Le Modèle peut déclencher des événements, mais le Présentateur s'abonne à eux pour la mise à jour de la Vue. Passive Vue il n'y a pas de liaison directe de données, au lieu de la Vue expose setter propriétés qui le Présentateur utilise pour définir les données. Tout état est géré dans le Présentateur et non de la Vue.
La supervision du Contrôleur: Le Présentateur poignées utilisateur gestes. La Vue se lie au Modèle directement via la liaison de données. Dans ce cas, il est le Présentateur de passer le Modèle de la Vue, de sorte qu'il peut se lier à elle. Le Présentateur va aussi contenir la logique pour des gestes comme appuyer sur un bouton, la navigation, etc.
Dans le MVC, le Contrôleur est responsable de la détermination de la Vue qui est affiché en réponse à toute action, y compris lors du chargement de l'application. Cela diffère de MVP où les actions de l'itinéraire à travers le point de Vue de l'animateur. Dans MVC, chaque action dans la Vue en corrélation avec un appel à un Contrôleur avec une action. Dans le web chaque action implique un appel à une URL, de l'autre côté de laquelle il y a un Contrôleur qui répond. Une fois que le Contrôleur a terminé son traitement, il sera de retour la Vue correcte. La séquence se poursuit de cette manière tout au long de la vie de l'application:
Action dans la Vue -> Appel à un Contrôleur -> Contrôleur De Logique -> Contrôleur retourne la Vue.
Une autre grande différence sur MVC est que l'avis ne lie pas directement sur le Modèle. Le point de vue simplement rend, et est complètement apatrides. Dans les implémentations de la MVC le point de Vue habituellement n'aura pas de logique dans le code derrière. Cela est contraire à la MVP où il est absolument nécessaire que si la Vue n'est pas délégué à l'animateur, il ne sera jamais appelé.
Un autre motif à regarder est la Présentation du Modèle le modèle. Dans ce modèle il n'y a pas de Présentateur. Au lieu de cela, la Vue se lie directement à un Modèle de Présentation. Le Modèle de Présentation est un Modèle conçu spécifiquement pour la Vue. Cela signifie que ce Modèle peut exposer les propriétés que l'on n'aurait jamais mis sur un modèle de domaine que ce serait une violation de la séparation des préoccupations. Dans ce cas, le Modèle de Présentation lie pour le modèle de domaine, et peut s'abonner aux événements à venir à partir de ce Modèle. La Vue, puis s'abonne aux événements à venir à partir de la Présentation du Modèle et des mises à jour en conséquence. Le Modèle de Présentation peuvent exposer les commandes dont la vue utilise pour invoquer des actions. L'avantage de cette approche est que vous pouvez supprimer le code-behind tout à fait comme les PM complètement encapsule tous les comportements de la vue. Ce modèle est un très bon candidat pour une utilisation dans des applications WPF et est également appelé" Model-View-ViewModel.
Il y a un article MSDN sur le Modèle de Présentation et une section dans le Composite guide d'Application en WPF (ancien Prisme) à propos d'une Présentation Séparée des Modèles
J'ai blogué sur ce dos pendant une, de citer sur Todd Snyder excellent post sur la différence entre les deux.
Voici les principales différences entre les modèles:
Modèle MVP
- La vue est plus faiblement couplé au modèle. Le présentateur est responsable de la liaison du modèle de le point de vue.
- Plus facile de test de l'unité parce que l'interaction avec le point de vue est par le biais de une interface
- Habituellement vue de presenter la carte les un à un. Des vues complexes peuvent avoir multi les présentateurs.
Modèle MVC
- Contrôleur sont basés sur les comportements et peuvent être partagées à travers vues
- Peut être responsable de la détermination de l'affichage
La meilleure explication sur le web j'ai pu trouver.
MVP est pas nécessairement un scénario où la Vue est en charge (voir Taligent titre de joueur par exemple).
Je trouve ça dommage que les gens sont toujours la prédication de ce genre (Vue en charge), par opposition à un anti-modèle car il est en contradiction avec "C'est juste un point de vue" (pragmatic programmer). "C'est juste un point de vue", la dernière vue affichée à l'utilisateur est une préoccupation secondaire de l'application. Microsoft MVP modèle rend la réutilisation des Vues beaucoup plus difficile et idéalement des excuses de Microsoft designer d'encourager une mauvaise pratique.
Pour être tout à fait franc, je pense que les préoccupations sous-jacentes de la MVC vrai pour tout le MVP de la mise en œuvre et les différences sont presque entièrement sémantique. Tant que vous êtes après la séparation des préoccupations entre le point de vue (qui affiche les données), le contrôleur (qui initialise et les contrôles de l'interaction de l'utilisateur) et le modèle (les données sous-jacentes et/ou services)), alors vous êtes obtenir les avantages de la MVC. Si vous êtes obtenir les avantages puis qui se soucie vraiment de savoir si votre modèle est MVC, MVP ou de la Supervision du Contrôleur? Le seul véritable motif reste que MVC, le reste ne sont que différentes saveurs.
Considérez cela très passionnant article qui complète énumère un certain nombre de ces différentes implémentations. Vous pouvez noter qu'ils sont tous essentiellement faire la même chose mais de façon légèrement différente.
Personnellement, je pense que le MVP a été récemment re-présenté comme une accrocheuse terme afin de réduire les arguments entre sémantique des fanatiques qui prétendent savoir si quelque chose est vraiment MVC ou pas, ou pour justifier les Microsoft les outils de Développement Rapide. Aucune de ces raisons dans mes livres de justifier son existence en tant que distincte de modèle de conception.
Le MVP de la Vue est en charge.
Le point de Vue, dans la plupart des cas, il crée du Présentateur. Le Présentateur va interagir avec le modèle et de manipuler la Vue à travers une interface. Le point de Vue parfois interagir avec le Présentateur, généralement par le biais d'une interface. Cela revient à la mise en œuvre, voulez-vous de les Afficher à l'appel de méthodes sur le présentateur ou voulez-vous le point de Vue d'événements le Présentateur écoute. Il se résume à ceci: Le point de Vue sait sur le Présentateur. Le point de Vue des délégués pour le Présentateur.
MVC le Contrôleur est en charge.
Le contrôleur est créé ou accessibles selon certaines événement/de la requête, le contrôleur crée ensuite la Vue appropriée et interagit avec le Modèle de configurer la Vue. Il se résume à: Contrôleur crée et gère, Vue est esclave sur le Contrôleur. La vue ne sais pas à propos de Contrôleur.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
