design-patterns - pattern - mvp vs mvc




Que sont MVP et MVC et quelle est la différence? (16)

Modèle-vue-présentateur

Dans MVP , le présentateur contient la logique métier de l'interface utilisateur pour la vue. Toutes les invocations du délégué View directement à Presenter. Le présentateur est également découplé directement de la vue et lui parle via une interface. Cela permet de se moquer de la vue dans un test unitaire. Un attribut commun de MVP est qu'il doit y avoir beaucoup de dispatching dans les deux sens. Par exemple, lorsque quelqu'un clique sur le bouton "Enregistrer", le gestionnaire d'événement délègue à la méthode "OnSave" du présentateur. Une fois la sauvegarde terminée, le présentateur rappellera la vue via son interface afin que la vue puisse afficher que la sauvegarde est terminée.

MVP a tendance à être un modèle très naturel pour obtenir une présentation séparée dans Web Forms. La raison en est que la vue est toujours créée en premier par le runtime ASP.NET. Vous pouvez en savoir plus sur les deux variantes .

Deux variations primaires

Vue passive: La vue est aussi bête que possible et ne contient quasiment aucune logique. Le présentateur est un intermédiaire qui parle de la vue et du modèle. La vue et le modèle sont complètement protégés l'un de l'autre. Le modèle peut déclencher des événements, mais le présentateur s'y abonne pour mettre à jour la vue. Dans la vue passive, il n’existe aucune liaison de données directe; au lieu de cela, la vue expose les propriétés de définition que le présentateur utilise pour définir les données. Tous les états sont gérés dans le présentateur et non dans la vue.

  • Pro: surface de testabilité maximale; séparation nette de la vue et du modèle
  • Con: plus de travail (par exemple, toutes les propriétés de définition) car vous vous associez toutes les données.

Contrôleur de supervision: le présentateur gère les gestes de l'utilisateur. La vue se lie directement au modèle via la liaison de données. Dans ce cas, le travail du présentateur consiste à transférer le modèle à la vue afin qu'il puisse s'y lier. Le présentateur contiendra également une logique pour les gestes comme appuyer sur un bouton, naviguer, etc.

  • Pro: en utilisant la liaison de données, la quantité de code est réduite.
  • Contre: il y a moins de surface testable (à cause de la liaison de données) et moins d'encapsulation dans la vue car elle communique directement avec le modèle.

Modèle Vue Contrôleur

Dans le MVC , le contrôleur est responsable de la détermination de la vue à afficher en réponse à une action, y compris lors du chargement de l'application. Cela diffère de MVP où les actions acheminent de la vue à l'animateur. Dans MVC, chaque action de la vue est en corrélation avec un appel à un contrôleur et une action. Sur le Web, chaque action implique un appel à une URL située de l'autre côté de laquelle un contrôleur répond. Une fois que ce contrôleur a terminé son traitement, il retournera la vue correcte. La séquence se poursuit de cette manière tout au long de la vie de l’application:

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

Une autre grande différence concernant MVC est que la vue ne se lie pas directement au modèle. La vue est simplement restituée et est complètement apatride. Dans les implémentations de MVC, la vue n'a généralement aucune logique dans le code. Ceci est contraire à MVP où cela est absolument nécessaire car, si la vue ne délègue pas à l'animateur, elle ne sera jamais appelée.

Modèle de présentation

Un autre motif à examiner est le motif Modèle de présentation . 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 spécialement conçu pour la vue. Cela signifie que ce modèle peut exposer des propriétés que l'on ne mettrait jamais dans un modèle de domaine, car cela constituerait une violation de la séparation des préoccupations. Dans ce cas, le modèle de présentation se lie au modèle de domaine et peut s'abonner aux événements provenant de ce modèle. La vue s'abonne ensuite aux événements provenant du modèle de présentation et se met à jour en conséquence. Le modèle de présentation peut exposer les commandes que la vue utilise pour appeler des actions. L'avantage de cette approche est que vous pouvez essentiellement supprimer complètement le code en retard, car le PM encapsule complètement tout le comportement de la vue. Ce modèle est un très bon candidat pour une utilisation dans les applications WPF et est également appelé Model-View-ViewModel .

Il existe un article MSDN sur le modèle de présentation et une section du guide d’application composite pour WPF (ancien Prism) sur les modèles de présentation séparés.

Lorsque vous regardez au-delà de la méthode RAD (glisser-déposer et configurer) de construction d'interfaces utilisateur, de nombreux outils vous incitent à rencontrer trois modèles de conception appelés Model-View-Controller , Model-View-Presenter et Model-View-ViewModel . Ma question comporte trois parties:

  1. Quels sont les problèmes abordés par ces modèles?
  2. Comment sont-ils similaires?
  3. Comment sont-ils différents?

MVP: la vue est en charge.

La vue, dans la plupart des cas, crée son présentateur. Le présentateur interagira avec le modèle et manipulera la vue via une interface. La vue interagit parfois avec le présentateur, généralement via une interface. Cela revient à la mise en œuvre; Voulez-vous que la vue appelle des méthodes sur le présentateur ou voulez-vous que la vue contienne des événements que le présentateur écoute? Cela se résume à ceci: la vue connaît le présentateur. La vue délègue au présentateur.

MVC: le contrôleur est en charge.

Le contrôleur est créé ou accessible en fonction de certains événements / demandes. Le contrôleur crée ensuite la vue appropriée et interagit avec le modèle pour configurer davantage la vue. Cela revient à: le contrôleur crée et gère la vue; la vue est esclave du contrôleur. La vue ne sait pas à propos du contrôleur.


Ces deux cadres visent à séparer les préoccupations - par exemple, l’interaction avec une source de données (modèle), la logique de l’application (ou la transformation de ces données en informations utiles) (Contrôleur / Présentateur) et le code d’affichage (View). Dans certains cas, le modèle peut également être utilisé pour transformer une source de données en une abstraction de niveau supérieur. Le projet MVC Storefront en est un bon exemple.

Il y a une discussion here concernant les différences entre MVC et MVP.

La distinction faite est que dans une application MVC a traditionnellement la vue et le contrôleur interagit avec le modèle, mais pas entre eux.

Les conceptions MVP permettent au présentateur d'accéder au modèle et d'interagir avec la vue.

Cela dit, ASP.NET MVC est par ces définitions une infrastructure MVP car le contrôleur accède au modèle pour renseigner la vue censée ne comporter aucune logique (affiche uniquement les variables fournies par le contrôleur).

Pour avoir peut-être une idée de la distinction entre ASP.NET MVC et MVP, consultez cette présentation MIX de Scott Hanselman.


Dans MVP, la vue extrait les données du présentateur qui dessine et prépare / normalise les données du modèle, tandis que dans MVC, le contrôleur extrait les données du modèle et les définit en poussant dans la vue.

Dans MVP, vous pouvez avoir une seule vue fonctionnant avec plusieurs types de présentateurs et un seul présentateur travaillant avec plusieurs vues différentes.

MVP utilise généralement une sorte d'infrastructure de liaison, telle que l'infrastructure de liaison Microsoft WPF ou divers infrastructures de liaison pour HTML5 et Java.

Dans ces cadres, l’interface utilisateur / HTML5 / XAML sait quelle propriété du présentateur est affichée par chaque élément d'interface utilisateur. Ainsi, lorsque vous liez une vue à un présentateur, celle-ci recherche les propriétés et sait comment en tirer des données. pour les définir lorsqu'une valeur est modifiée dans l'interface utilisateur par l'utilisateur.

Ainsi, si, par exemple, le modèle est une voiture, le présentateur est une sorte de présentateur de voiture et expose les propriétés de la voiture (année, constructeur, sièges, etc.) à la vue. La vue sait que le champ de texte appelé "constructeur" doit afficher la propriété Maker du présentateur.

Vous pouvez ensuite lier à la vue de nombreux types de présentateurs différents. Tous doivent avoir la propriété Maker - que ce soit un avion, un train ou autre chose, la vue n’a aucune importance. La vue tire des données du présentateur - peu importe lequel - tant qu'il implémente une interface convenue.

Ce framework contraignant, si vous le déshabillez, c'est en fait le contrôleur :-)

Et ainsi, vous pouvez considérer MVP comme une évolution de MVC.

MVC est génial, mais le problème est que, généralement, son contrôleur est affiché. Le contrôleur A sait comment définir les champs de la vue A. Si maintenant, vous voulez que la vue A affiche les données du modèle B, vous avez besoin du contrôleur A pour connaître le modèle B, ou du contrôleur A pour recevoir un objet avec une interface - comme MVP uniquement sans les liaisons, ou vous devez réécrire le code de jeu d'interface utilisateur dans le contrôleur B.

Conclusion - MVP et MVC sont tous deux des découplages de modèles d'interface utilisateur, mais MVP utilise généralement un framework de liaisons qui est MVC en dessous. THUS MVP est à un niveau architectural supérieur à MVC et à un modèle d'enveloppe supérieur à celui de MVC.


Il y a beaucoup de réponses à la question, mais j’ai senti le besoin d’une réponse très simple comparant clairement les deux. Voici la discussion que j'ai faite lorsqu'un utilisateur recherche un nom de film dans une application MVP et MVC:

Utilisateur: cliquez, cliquez…

Voir : Qui est-ce? [ MVP | MVC ]

Utilisateur: je viens de cliquer sur le bouton de recherche…

Voir : Ok, attendez une seconde…. [ MVP | MVC ]

( Voir pour appeler le présentateur | Contrôleur …) [ MVP | MVC ]

Voir : Hey Présentateur | Contrôleur , un utilisateur vient de cliquer sur le bouton de recherche, que dois-je faire? [ MVP | MVC ]

Présentateur | Contrôleur : Hey View , y a-t-il un terme de recherche sur cette page? [ MVP | MVC ]

Vue : Oui,… la voici… “piano” [ MVP | MVC ]

Présentateur : Merci,… pendant ce temps, je cherche le terme de recherche sur le modèle , montrez-lui s'il vous plaît une barre de progression [ MVP | MVC ]

(Le présentateur | Le contrôleur appelle le modèle …) [ MVP | MVC ]

Présentateur | Contrôleur : Hé, modèle , avez-vous une correspondance pour ce terme de recherche ?: “piano” [ MVP | MVC ]

Modèle : Hey Presenter | Contrôleur , laissez-moi vérifier… [ MVP | MVC ]

(Le modèle envoie une requête à la base de données de films…) [ MVP | MVC ]

( Après un moment ... )

-------------- C'est ici que MVP et MVC commencent à diverger ---------------

Modèle : j'ai trouvé une liste pour vous, présentateur , la voici en JSON “[{" nom ":" professeur de piano "," année ": 2001}, {" nom ":" piano "," année ": 1993} ] ”[ MVP ]

Modèle : Il y a des résultats disponibles, Contrôleur . J'ai créé une variable de champ dans mon instance et l'ai renseignée avec le résultat. Son nom est "searchResultsList" [ MVC ]

(Le présentateur | Le contrôleur remercie Model et revient à la vue ) [ MVP | MVC ]

Animateur : Merci d’avoir attendu View , j’ai trouvé une liste de résultats correspondants pour vous et les ai classés dans un format pouvant être visualisé : ["Piano Teacher 2001", "Piano 1993"]. S'il vous plaît le montrer à l'utilisateur dans une liste verticale. Veuillez également masquer la barre de progression maintenant [ MVP ]

Contrôleur : Merci d’avoir attendu View , j’ai demandé à Model de vous interroger. Il dit qu'il a trouvé une liste de résultats correspondants et les a stockés dans une variable nommée "searchResultsList" à l'intérieur de son instance. Vous pouvez l'obtenir à partir de là. Veuillez également masquer la barre de progression maintenant [ MVC ]

Voir : Merci beaucoup Présentateur [ MVP ]

Vue : Merci "Contrôleur" [ MVC ] (Maintenant, la vue se questionne: comment dois-je présenter les résultats obtenus par le modèle à l'utilisateur? L'année de production du film doit-elle être la première ou la dernière ...? être dans une liste verticale ou horizontale? ...)

Au cas où cela vous intéresserait, j'ai rédigé une série d'articles sur les modèles architecturaux des applications (MVC, MVP, MVVP, architecture propre, ...) accompagnés d'un dépôt Github here . Même si l'échantillon est écrit pour Android, les principes sous-jacents peuvent être appliqués à n'importe quel support.



Je bloguais à ce sujet il y a quelque temps, citant l'excellent message de Todd Snyder 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ée au modèle. Le présentateur est responsable de la liaison du modèle à la vue.
  • Plus facile à tester à l'unité car l'interaction avec la vue se fait via une interface
  • Généralement, affichez la carte du présentateur une par une. Les vues complexes peuvent avoir plusieurs présentateurs.

Modèle MVC

  • Les contrôleurs sont basés sur des comportements et peuvent être partagés entre des vues.
  • Peut être responsable de déterminer quelle vue afficher

C'est la meilleure explication sur le web que j'ai pu trouver.


Les deux modèles tentent de séparer la présentation et la logique métier, en dissociant la logique métier des aspects de l'interface utilisateur.

Sur le plan architectural, MVP est une approche basée sur le contrôleur de page, tandis que MVC est une approche basée sur le contrôleur frontal. Cela signifie que le cycle de vie des pages de formulaires Web standard MVP est simplement amélioré en extrayant la logique métier à partir du code. En d’autres termes, page est la requête http à service unique. En d'autres termes, MVP IMHO est un type évolutif de formulaire Web. D'autre part, MVC change complètement le jeu car la requête est interceptée par la classe du contrôleur avant le chargement de la page, la logique métier y est exécutée, puis au résultat final du traitement par le contrôleur des données qui viennent d'être vidées dans la page ("vue"). En ce sens, MVC ressemble (du moins pour moi) à la saveur de contrôleur de supervision de MVP améliorée avec le moteur de routage.

Les deux permettent le TDD et présentent des inconvénients et des avantages.

La décision sur la façon de choisir l’un d’entre eux, IMHO, devrait être basée sur le temps qu’on a investi dans le développement Web de type formulaire ASP NET. Si on se considérait bon dans les formulaires Web, je suggérerais MVP. Si vous ne vous sentiez pas à l'aise dans des choses telles que le cycle de vie d'une page, etc., MVC pourrait être une solution.

Voici encore un autre lien de blog donnant un peu plus de détails sur ce sujet

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx


Voici des illustrations qui représentent le flux de communication




MVC (contrôleur de vue modèle)

L'entrée est d'abord dirigée vers le contrôleur, pas vers la vue. Cette entrée peut provenir d'un utilisateur interagissant avec une page, mais peut-être aussi simplement en entrant une URL spécifique dans un navigateur. Dans les deux cas, c'est un contrôleur qui est interfacé avec pour lancer certaines fonctionnalités. Il existe une relation plusieurs-à-un entre le contrôleur et la vue. En effet, un seul contrôleur peut sélectionner différentes vues à restituer en fonction de l'opération en cours d'exécution. Notez la flèche à sens unique du contrôleur à la vue. Cela est dû au fait que la vue n'a aucune connaissance ou référence du contrôleur. Le contrôleur retransmet le modèle. Il y a donc des informations entre la vue et le modèle attendu, mais pas le contrôleur qui le sert.

MVP (présentateur de vue modèle)

La saisie commence par la vue, pas par le présentateur. Il existe un mappage univoque entre la vue et le présentateur associé. La vue contient une référence à l'animateur. Le présentateur réagit également aux événements déclenchés à partir de la vue. Il est donc informé de la vue à laquelle il est associé. Le présentateur met à jour la vue en fonction des actions demandées qu'il effectue sur le modèle, mais la vue n'est pas compatible avec le modèle.

Pour plus de Reference


Modèle Vue Contrôleur

MVC est un modèle pour l'architecture d'une application logicielle. Il sépare la logique d'application en trois parties distinctes, favorisant la modularité et la facilité de collaboration et de réutilisation. Cela rend également les applications plus flexibles et plus accueillantes pour les itérations. Il sépare une application en composants suivants:

  • Modèles de traitement des données et logique métier
  • Contrôleurs pour gérer l'interface utilisateur et l'application
  • Vues permettant de gérer les objets d'interface utilisateur graphique et la présentation

Pour rendre cela un peu plus clair, imaginons une application simple de liste de courses. Tout ce que nous voulons, c'est une liste du nom, de la quantité et du prix de chaque article que nous devons acheter cette semaine. Nous décrivons ci-dessous comment nous pourrions implémenter certaines de ces fonctionnalités à l'aide de MVC.

Modèle-vue-présentateur

  • Le modèle correspond aux données qui seront affichées dans la vue (interface utilisateur).
  • La vue est une interface qui affiche des données (le modèle) et achemine les commandes utilisateur (événements) vers le présentateur afin qu’elles agissent sur ces données. La vue fait généralement référence à son présentateur.
  • Le présentateur est «l'homme du milieu» (joué par le contrôleur dans MVC) et a des références à la fois, vue et modèle. Veuillez noter que le mot "Modèle" est trompeur. Ce devrait être plutôt une logique métier qui récupère ou manipule un modèle . Par exemple: si vous avez une base de données stockant l'utilisateur dans une table de base de données et que votre vue souhaite afficher une liste d'utilisateurs, le présentateur aura alors une référence à la logique commerciale de votre base de données (comme un DAO) à partir de laquelle le présentateur interrogera une liste. des utilisateurs.

Si vous voulez voir un exemple avec une implémentation simple, veuillez vérifier this GitHub

Un flux de travail concret consistant à interroger et à afficher une liste d'utilisateurs d'une base de données pourrait fonctionner comme suit:

Quelle est la différence entre les modèles MVC et MVP ?

Modèle MVC

  • Les contrôleurs sont basés sur des comportements et peuvent être partagés entre des vues.

  • Peut être responsable de déterminer quelle vue à afficher (modèle de contrôleur frontal)

Modèle MVP

  • La vue est plus faiblement couplée au modèle. Le présentateur est responsable de la liaison du modèle à la vue.

  • Plus facile à tester à l'unité car l'interaction avec la vue se fait via une interface

  • Généralement, affichez la carte du présentateur une par une. Les vues complexes peuvent avoir plusieurs présentateurs.



Je pense que cette image d'Erwin Vandervalk (et l' article accompagnement ) constitue la meilleure explication de MVC, MVP et MVVM, de leurs similitudes et de leurs différences. L' article n'apparaît pas dans les résultats des moteurs de recherche pour les requêtes sur "MVC, MVP et MVVM" car le titre de l'article ne contient pas les mots "MVC" et "MVP"; mais c'est la meilleure explication, je pense.

(L' article correspond également à ce que l'oncle Bob Martin a dit dans l'un de ses discours: MVC a été conçu à l'origine pour les petits composants de l'interface utilisateur, pas pour l'architecture du système)


La réponse la plus simple est la manière dont la vue interagit avec le modèle. Dans MVP, la vue est liée au présentateur, qui agit en tant qu'intermédiaire entre la vue et le modèle, en prenant des entrées à partir de la vue, en récupérant les données du modèle, en exécutant ensuite une logique métier et en mettant à jour la vue. Dans MVC, le modèle met à jour la vue directement plutôt que de revenir en arrière par le contrôleur.


Vous avez oublié Action-Domain-Responder ( ADR ).

Comme expliqué dans certains graphiques ci-dessus, il existe une relation directe entre le modèle et la vue dans MVC. Une action est effectuée sur le contrôleur , qui exécutera une action sur le modèle . Cette action dans le modèle , va déclencher une réaction dans le View . La vue est toujours mise à jour lorsque l' état du modèle change.

Certaines personnes ne cessent d'oublier que MVC a été créé à la fin des années 70 " et que le Web n'a été créé qu'à la fin des années 80" / début des années 90 ". MVC n'a pas été créé à l'origine pour le Web, mais pour les applications de bureau, où le contrôleur , Modèle et Vue coexisteraient ensemble.

Parce que nous utilisons des frameworks Web ( par exemple: Laravel ) qui utilisent toujours les mêmes conventions de nommage ( modèle-vue-contrôleur ), nous avons tendance à penser que ce doit être MVC, mais en réalité c'est autre chose.

Regardez plutôt ADR . Dans ADR, le contrôleur obtient une action qui effectuera une opération dans le modèle / domaine . Jusqu'ici, les mêmes. La différence est qu’il collecte ensuite la réponse / les données de cette opération et le transmet à un répondeur ( par exemple :.view() ) pour le rendu. Lorsqu'une nouvelle action est demandée sur le même composant, le contrôleur est rappelé et le cycle se répète. Dans ADR, il n'y a pas de connexion entre le modèle / domaine et la vue ( réponse de Reponser ).

Remarque: Wikipedia indique que " chaque action ADR, cependant, est représentée par des classes ou des fermetures séparées ". Ce n'est pas nécessairement vrai. Plusieurs actions peuvent être dans le même contrôleur, et le motif est toujours le même.

mvc adr model-view-controller action-domain-responder


  • MVP = Model-View-Presenter
  • MVC = Model-View-Controller

    1. Les deux modèles de présentation. Ils séparent les dépendances entre un modèle (objets du domaine think), votre écran / page Web (la vue) et le comportement de votre interface utilisateur (présentateur / contrôleur).
    2. Leur concept est assez similaire, les gens initialisent le présentateur / contrôleur différemment selon les goûts.
    3. Un excellent article sur les différences est here . Le plus notable est que le modèle MVC a le modèle mettant à jour la vue.




glossary