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

2133

Lorsque vous regardez au-delà de la façon RAD (glisser-déposer et configurer) de créer des interfaces utilisateur que de nombreux outils vous encouragent, vous risquez de 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 problèmes ces modèles répondent-ils?
  2. En quoi sont-ils similaires?
  3. Comment sont-ils différents?
Mike Minutillo
la source
4
mvc.givan.se/#mvp
givanse
2
IDK, mais soi-disant pour le MVC d'origine, il était destiné à être utilisé dans le petit. Chaque bouton, étiquette, etc., avait sa propre vue et son propre objet contrôleur, ou du moins c'est ce que prétend l'oncle Bob. Je pense qu'il parlait de Smalltalk. Recherchez ses discussions sur YouTube, elles sont fascinantes.
still_dreaming_1
MVP ajoute une couche supplémentaire d'indirection en divisant le View-Controller en une vue et un présentateur ...
the_prole
2
La principale différence est que dans MVC, le contrôleur ne transmet aucune donnée du modèle à la vue. Il avertit simplement la vue pour obtenir les données du modèle lui-même. Cependant, dans MVP, il n'y a pas de connexion entre la vue et le modèle. Le présentateur lui-même obtient toutes les données nécessaires du modèle et les transmet à la vue pour les afficher. Plus à cela avec un échantillon Android dans tous les modèles d'architecture est ici: digigene.com/category/android/android-architecture
Ali Nem
On les appelle des modèles architecturaux et non des modèles de conception . Si vous voulez connaître la différence, vérifiez ceci
Hasan El-Hefnawy

Réponses:

1997

Model-View-Presenter

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 vers 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 répartition bidirectionnelle. Par exemple, lorsque quelqu'un clique sur le bouton "Enregistrer", le gestionnaire d'événements délègue à la méthode "OnSave" du présentateur. Une fois la sauvegarde terminée, le présentateur rappellera alors 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 réaliser une présentation séparée dans les formulaires Web. 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 variantes principales

Vue passive: la vue est aussi stupide que possible et contient une logique presque nulle. Le présentateur est un intermédiaire qui parle à la vue et au 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 y souscrit pour mettre à jour la vue. Dans la vue passive, il n'y a pas de liaison de données directe, mais la vue expose les propriétés de setter que le présentateur utilise pour définir les données. Tout l'état est géré dans le présentateur et non dans la vue.

  • Pro: surface de testabilité maximale; séparation nette de la vue et du modèle
  • Inconvénient: plus de travail (par exemple toutes les propriétés du setter) car vous effectuez vous-même toutes les données.

Contrôleur superviseur: 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 à transmettre le modèle à la vue afin qu'il puisse s'y lier. Le présentateur contiendra également une logique pour les gestes tels que la pression d'un bouton, la navigation, etc.

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

Modèle Vue Contrôleur

Dans le MVC , le contrôleur est responsable de déterminer quelle vue afficher en réponse à toute action, y compris lorsque l'application se charge. Cela diffère de MVP où les actions sont acheminées via la vue vers le présentateur. Dans MVC, chaque action dans la vue est en corrélation avec un appel à un contrôleur avec une action. Sur le Web, chaque action implique un appel à une URL de l'autre côté de laquelle un contrôleur répond. Une fois que le contrôleur a terminé son traitement, il renverra 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 au contrôleur
        -> Logique du contrôleur
        -> Le contrôleur renvoie la vue.

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

Modèle de présentation

Un autre modèle à regarder est le modèle de présentationmodè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 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 sur un modèle de domaine car ce serait 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 à des é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-behind car le PM encapsule complètement tout le comportement de la vue.Model-View-ViewModel .

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

Glenn Block
la source
27
Pouvez-vous clarifier cette phrase? Cela diffère de MVP où les actions sont acheminées via la vue vers le présentateur. Dans MVC, chaque action dans la vue est en corrélation avec un appel à un contrôleur avec une action. Pour moi, cela ressemble à la même chose, mais je suis sûr que vous décrivez quelque chose de différent.
Panzercrisis
16
@Panzercrisis Je ne sais pas si c'est ce que l'auteur voulait dire, mais c'est ce que je pense qu'ils essayaient de dire. Comme cette réponse - stackoverflow.com/a/2068/74556 mentionne, dans MVC, les méthodes de contrôleur sont basées sur des comportements - en d'autres termes, vous pouvez mapper plusieurs vues (mais le même comportement) à un seul contrôleur. Dans MVP, le présentateur est couplé plus près de la vue, et se traduit généralement par un mappage qui est plus proche de un à un, c'est-à-dire qu'une action de vue correspond à la méthode de son présentateur correspondant. En règle générale, vous ne mapperiez pas les actions d'une autre vue à la méthode d'un autre présentateur (à partir d'une autre vue).
Dustin Kendall du
2
Notez que cela MVC est souvent utilisé par des frameworks web comme Laravel, où les requêtes URL reçues (peut-être faites par les utilisateurs) sont traitées par le Controlleret le HTML généré par le Viewest envoyé au client - Donc, le Viewfait partie du backend et du l'utilisateur ne peut jamais y accéder directement, et si vous rencontrez le contraire, considérez cela comme une extension MVC (ou même une violation). @Panzercrisis, Cela diffère de MVP(comme celui utilisé dans le Androidsystème d'exploitation) où actions route through the View to the Presenteret l'utilisateur a un accès direct au View.
Top-Master
455

Il s'agit d'une simplification excessive des nombreuses variantes de ces modèles de conception, mais c'est ainsi que j'aime penser les différences entre les deux.

MVC

MVC

MVP

entrez la description de l'image ici

Phyxx
la source
10
Ceci est une excellente représentation du schéma, montrant l'abstraction et l'isolement complet de tout GUI lié (voir les trucs) de l'API du présentateur. Un point mineur: un présentateur principal peut être utilisé lorsqu'il n'y a qu'un seul présentateur, plutôt qu'un seul par vue, mais votre diagramme est le plus propre. OMI, la plus grande différence entre MVC / MVP est que MVP essaie de garder la vue totalement vide de tout autre chose que l'affichage de l'état de vue actuel (données de vue), tout en interdisant à la vue toute connaissance des objets du modèle. Ainsi les interfaces, devant être là, pour injecter cet état.
4
Bonne image. J'utilise beaucoup MVP, donc je voudrais faire un point. D'après mon expérience, les présentateurs ont besoin de se parler assez souvent. Il en va de même pour les modèles (ou objets métier). En raison de ces «lignes bleues» de communication supplémentaires qui figureraient dans votre image MVP, les relations entre le présentateur et le modèle peuvent devenir assez intriquées. Par conséquent, j'ai tendance à garder une relation Présentateur-Modèle un contre un par rapport à une relation un à plusieurs. Oui, cela nécessite des méthodes déléguées supplémentaires sur le modèle, mais cela réduit de nombreux maux de tête si l'API du modèle change ou doit être refactorisée.
splungebob
3
L'exemple MVC est faux; il existe une relation stricte 1: 1 entre les vues et les contrôleurs. Par définition, un contrôleur interprète l'entrée du geste humain pour produire des événements pour le modèle et les visualiser de la même façon pour un seul contrôle. Plus simplement, MVC a été conçu pour être utilisé uniquement avec des widgets individuels. Un widget, une vue, un contrôle.
Samuel A. Falvo II
3
@ SamuelA.FalvoII pas toujours, il y a un 1: beaucoup entre les contrôleurs et les vues dans ASP.NET MVC: stackoverflow.com/questions/1673301/…
StuperUser
4
@StuperUser - Je ne sais pas à quoi je pensais quand j'ai écrit ça. Vous avez raison, bien sûr, et en repensant à ce que j'ai écrit, je dois me demander si j'avais un autre contexte en tête que je n'ai pas réussi à articuler. Merci pour la correction.
Samuel A. Falvo II
421

J'ai blogué à ce sujet il y a quelque temps, citant l'excellent post 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 lâchement couplée au modèle. Le présentateur est responsable de la liaison du modèle à la vue.
  • Test unitaire plus facile car l'interaction avec la vue se fait via une interface
  • Généralement, affichez la carte du présentateur une à une. Les vues complexes peuvent avoir plusieurs présentateurs.

Modèle MVC

  • Le contrôleur est basé sur les comportements et peut être partagé entre les vues
  • Peut être responsable de déterminer la vue à afficher

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

Jon Limjap
la source
15
Je ne comprends pas comment la vue peut être couplée plus ou moins étroitement au modèle alors que dans les deux cas, il s'agit de les découpler complètement. Je ne veux pas dire que vous avez dit quelque chose de mal - juste confus quant à ce que vous voulez dire.
Bill K
18
@pst: avec MVP c'est vraiment 1 View = 1 Presenter. Avec MVC, le contrôleur peut gouverner plusieurs vues. Voilà, vraiment. Avec le modèle des "onglets", imaginez que chaque onglet ait son propre Presenter au lieu d'avoir un contrôleur pour tous les onglets.
Jon Limjap
4
À l'origine, il existe deux types de contrôleurs: celui que vous avez dit partagé entre plusieurs vues, et ceux qui sont spécifiques aux vues, principalement destinés à adapter l'interface du contrôleur partagé.
Acsor
1
@JonLimjap Qu'est-ce que cela signifie de toute façon? Dans le contexte de la programmation iOS, est-ce un écran? Cela fait-il que le contrôleur iOS ressemble plus à MVP qu'à MVC? (D'un autre côté, vous pouvez également avoir plusieurs contrôleurs iOS par écran)
huggie
2
Eh bien, l'illustration schématique de Todd de MVC contredit complètement l'idée de découpler la vue et le modèle. Si vous regardez le diagramme, il indique que le modèle met à jour la vue (flèche du modèle à la vue). Dans quel univers est un système, où le modèle interagit directement avec la vue, découplé ???
Ash
260

Voici des illustrations qui représentent le flux de communication

entrez la description de l'image ici

entrez la description de l'image ici

Ashraf Bashir
la source
44
J'ai une question concernant le diagramme MVC. Je ne reçois pas la partie où la vue sort pour récupérer les données. Je pense que le contrôleur transmettrait à la vue avec les données nécessaires.
Brian Rizo
54
Si un utilisateur clique sur un bouton, comment cela n'interagit-il pas avec la vue? J'ai l'impression que dans MVC, l'utilisateur interagit avec la vue plus que le contrôleur
Jonathan
5
Je sais que c'est une vieille réponse - mais quelqu'un pourrait-il répondre au point @JonathanLeaders? Je viens d'un arrière-plan de winforms, sauf si vous avez fait un codage très unique, lorsque vous cliquez sur l'interface utilisateur / la vue obtient la connaissance de ce clic avant toute autre chose. Du moins, pour autant que je sache?
Rob P.
6
@RobP. Je pense que ces types de graphiques ont toujours tendance à être soit trop complexes, soit trop simples. Imo, le flux du graphique MVP est également vrai pour une application MVC. Il peut y avoir des variations, selon les fonctionnalités du langage (liaison de données / observateur), mais au final l'idée est de découpler la vue des données / logique de l'application.
Luca Fülbier
15
@JonathanLeaders Les gens ont des choses vraiment différentes à l'esprit quand ils disent "MVC". La personne qui a créé ce graphique avait probablement à l'esprit le Web MVC classique, où les «entrées utilisateur» sont des requêtes HTTP et la «vue retournée à l'utilisateur» est une page HTML rendue. Ainsi, toute interaction entre un utilisateur et une vue est "inexistante" du point de vue d'un auteur de l'application Web MVC classique.
cubuspl42
170

MVP n'est pas nécessairement un scénario où la Vue est en charge (voir MVP de Taligent par exemple).
Je trouve regrettable que les gens continuent de prêcher cela comme un modèle (View in charge) par opposition à un anti-pattern car il contredit "C'est juste une vue" (Programmeur Pragmatique). "C'est juste une vue" indique que la vue finale montrée à l'utilisateur est une préoccupation secondaire de l'application. Le modèle MVP de Microsoft rend la réutilisation des vues beaucoup plus difficile et pratique excuse le concepteur de Microsoft d'encourager les mauvaises pratiques.

Pour être parfaitement franc, je pense que les préoccupations sous-jacentes de MVC sont vraies pour toute implémentation MVP et les différences sont presque entièrement sémantiques. Tant que vous suivez la séparation des préoccupations entre la vue (qui affiche les données), le contrôleur (qui initialise et contrôle l'interaction utilisateur) et le modèle (les données et / ou services sous-jacents)), vous bénéficiez des avantages de MVC . Si vous obtenez les avantages, alors qui se soucie vraiment de savoir si votre modèle est MVC, MVP ou contrôleur superviseur? Le seul vrai modèle reste le MVC, les autres ne sont que des saveurs différentes.

Considérez cet article très intéressant qui répertorie de manière exhaustive un certain nombre de ces différentes implémentations. Vous pouvez noter qu'ils font tous fondamentalement la même chose mais légèrement différemment.

Personnellement, je pense que MVP n'a été réintroduit que récemment comme un terme accrocheur pour réduire les arguments entre les bigots sémantiques qui se demandent si quelque chose est vraiment MVC ou pour justifier les outils de développement rapide d'applications Microsofts. Aucune de ces raisons dans mes livres ne justifie son existence en tant que modèle de conception distinct.

Quibblesome
la source
28
J'ai lu plusieurs réponses et blogs sur les différences entre MVC / MVP / MVVM / etc '. En effet, quand on est aux affaires, c'est pareil. Peu importe que vous ayez une interface ou non, et que vous utilisiez un setter (ou toute autre fonctionnalité de langue). Il semble que la différence entre ces modèles soit née de la différence de mise en œuvre de divers cadres, plutôt que d'une question de concept.
Michael
6
Je n'appellerais pas MVP un anti-pattern , car plus tard dans le post "..le reste [y compris MVP] ne sont que des saveurs différentes de [MVC] ..", ce qui impliquerait que si MVP était un anti-pattern, alors était MVC ... c'est juste une saveur pour une approche de framework différente. (Maintenant, certaines implémentations MVP spécifiques peuvent être plus ou moins souhaitables que certaines implémentations MVC spécifiques pour différentes tâches ...)
@Quibblsome: «Personnellement, je pense que MVP n'a été réintroduit que récemment comme un terme accrocheur pour réduire les arguments entre les bigots sémantiques qui se demandent si quelque chose est vraiment MVC ou non […] Aucune de ces raisons dans mes livres ne justifie son existence en tant que modèle de conception distinct. " . Il diffère suffisamment pour le rendre distinct. Dans MVP, la vue peut être tout ce qui remplit une interface prédéfinie (la vue dans MVP est un composant autonome). Dans MVC, le contrôleur est fait pour une vue particulière (si les arités de la relation peuvent faire ressentir à quelqu'un que cela vaut un autre terme).
Hibou57
6
@ Hibou57, rien n'empêche MVC de référencer la vue en tant qu'interface ou de créer un contrôleur générique pour plusieurs vues différentes.
Quibblesome
1
Samuel, veuillez clarifier ce dont vous parlez. À moins que vous ne me racontiez l'histoire de l'équipe qui a "inventé" MVC, je suis incroyablement douteux à propos de votre texte. Si vous ne faites que parler de WinForm, il existe d'autres façons de faire les choses et j'ai créé des projets WinForm dans lesquels les liaisons de contrôle sont gérées par le contrôleur, pas les "contrôles individuels".
Quibblesome
110

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 ait des événements que le présentateur écoute? Cela se résume à ceci: la vue connaît le présentateur. Le point de vue délègue au présentateur.

MVC: le contrôleur est en charge.

Le contrôleur est créé ou accessible en fonction d'un événement / d'une demande. Le contrôleur crée ensuite la vue appropriée et interagit avec le modèle pour configurer davantage la vue. Cela se résume à: le contrôleur crée et gère la vue; la vue est esclave du contrôleur. La vue ne connaît pas le contrôleur.

Brian Leahy
la source
3
"View ne connaît pas Controller." Je pense que vous voulez dire que la vue n'a pas de contact direct avec le modèle?
Lotus Notes
2
La vue ne devrait jamais connaître le modèle dans eiether one.
Brian Leahy
4
@Brian: "La Vue, dans la plupart des cas, crée son Presenter." . J'ai surtout vu le contraire, le présentateur lançant à la fois le modèle et la vue. Eh bien, la vue peut également lancer le présentateur, mais ce point n'est pas vraiment le plus distinctif. Ce qui compte le plus se produit plus tard au cours de la vie.
Hibou57
2
Vous souhaiterez peut-être modifier votre réponse pour l'expliquer davantage: la vue ne connaissant pas le contrôleur, comment les actions de l'utilisateur, qui sont effectuées sur les éléments «visuels» que l'utilisateur voit à l'écran (c'est-à-dire la vue), sont-elles communiquées au contrôleur ...
Ash
77

entrez la description de l'image ici

MVC (Model View Controller)

L'entrée est dirigée vers le contrôleur en premier, pas vers la vue. Cette entrée peut provenir d'un utilisateur interagissant avec une page, mais elle peut également provenir de la simple saisie d'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 à rendre en fonction de l'opération en cours d'exécution. Notez la flèche unidirectionnelle du contrôleur vers la vue. En effet, la vue n'a aucune connaissance ni référence au contrôleur. Le contrôleur transmet le modèle, il y a donc une connaissance entre la vue et le modèle attendu qui lui est transmis, mais pas le contrôleur qui le sert.

MVP (Model View Presenter)

L'entrée commence par la vue, pas le présentateur. Il existe un mappage un à un entre la vue et le présentateur associé. La vue contient une référence au présentateur. Le présentateur réagit également aux événements déclenchés à partir de la vue, de sorte qu'il est conscient de la vue qui lui est associée. Le présentateur met à jour la vue en fonction des actions demandées qu'il exécute sur le modèle, mais la vue n'est pas compatible avec le modèle.

Pour plus de référence

AVI
la source
Mais dans le MVPmodèle, lorsque l'application se charge pour la première fois, le présentateur n'est-il pas chargé de charger la première vue? Comme par exemple lorsque nous chargeons l'application facebook, le présentateur n'est-il pas chargé de charger la page de connexion?
viper
2
Un lien du modèle à la vue dans MVC? Vous voudrez peut-être modifier votre réponse pour expliquer comment cela en fait un système «découplé», compte tenu de ce lien. Astuce: vous pouvez trouver cela difficile. De plus, à moins que vous ne pensiez que le lecteur acceptera volontiers qu'il a mal calculé toute sa vie, vous voudrez peut-être expliquer pourquoi les actions passent d'abord par Controller dans MVC malgré que l'utilisateur interagisse avec les éléments «visuels» à l'écran (c'est-à-dire le View), pas une couche abstraite derrière le traitement.
Ash
3
C'est clairement faux ... dans MVC, le modèle ne parle jamais directement avec la vue et vice versa. Ils ne savent même pas qu'un autre existe. Le contrôleur est la colle qui les
unit
1
Je suis d'accord avec Ash et MegaManX. Dans le diagramme MVC, la flèche doit provenir de la vue pointant vers le modèle (ou ViewModel ou DTO), pas du modèle vers la vue; car le modèle ne connaît pas la vue, mais la vue peut connaître le modèle.
Jboy Flaga
57

Il y a de nombreuses réponses à la question, mais j'ai senti le besoin d'une réponse vraiment 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 sur…

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

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

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

( Voir 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,… le voici… «piano» [ MVP | MVC ]

Présentateur : Merci Voir ,… en attendant je recherche le terme de recherche sur le modèle , veuillez lui montrer 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 fait une requête à la base de données de films…) [ MVP | MVC ]

( Après un moment ... )

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

Modèle : J'ai trouvé une liste pour vous, Présentateur , la voici en JSON "[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993} ] »[ MVP ]

Modèle : Il y a un résultat disponible, contrôleur . J'ai créé une variable de champ dans mon instance et l'ai remplie avec le résultat. Son nom est "searchResultsList" [ MVC ]

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

Présentateur : Merci d'avoir attendu View , j'ai trouvé une liste de résultats correspondants pour vous et les ai arrangés dans un format présentable: ["Piano Teacher 2001", "Piano 1993"]. Veuillez 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 votre requête de recherche. 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 ]

View : Merci beaucoup Presenter [ MVP ]

Vue : Merci "Contrôleur" [ MVC ] (Maintenant, la Vue se questionne: Comment dois-je présenter les résultats que j'obtiens du Modèle à l'utilisateur? L'année de production du film doit-elle venir en premier ou en dernier ...? Doit-elle être dans une liste verticale ou horizontale? ...)

Si vous êtes intéressé, j'ai écrit une série d'articles traitant des modèles architecturaux des applications (MVC, MVP, MVVP, architecture propre, ...) accompagné d'un dépôt Github ici . Même si l'échantillon est écrit pour Android, les principes sous-jacents peuvent être appliqués à n'importe quel support.

Ali Nem
la source
Fondamentalement, ce que vous essayez de dire, c'est que le contrôleur gère la logique de la vue? Cela rend donc la vue plus stupide en présentant ce qui se passe et comment sur les vues?
Radu
@Radu, Non, il ne fait pas de microgestion, c'est ce que fait le présentateur en rendant la vue passive ou muette
Ali Nem
4
Dans un MVC approprié, la vue appelle des fonctionnalités sur le contrôleur et écoute les modifications de données dans le modèle. La vue n'obtient pas de données du contrôleur, et le contrôleur ne doit PAS dire à la vue d'afficher, par exemple, un indicateur de chargement. Un MVC approprié vous permet de remplacer la partie vue, par une autre fondamentalement différente. La partie vue contient une logique de vue, qui comprend un indicateur de chargement. La vue appelle des instructions (dans le contrôleur), le contrôleur modifie les données dans le modèle et le modèle notifie ses écouteurs des modifications apportées à ses données, un tel écouteur est la vue.
Tommy Andersen
35
  • 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 (pensez aux objets de domaine), votre écran / page Web (la vue) et le comportement de votre interface utilisateur (présentateur / contrôleur)
    2. Ils sont assez similaires dans leur concept, les gens initialisent le présentateur / contrôleur différemment selon le goût.
    3. Un excellent article sur les différences est ici . Le plus remarquable est que le modèle MVC a le modèle mettant à jour la vue.
Brett Veenstra
la source
2
Modèle de mise à jour du VIew. Et c'est toujours un système découplé?
Ash
34

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. Il rend également les applications plus flexibles et plus accueillantes pour les itérations. Il sépare une application dans les composants suivants:

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

Pour rendre cela un peu plus clair, imaginons une application de liste de courses simple. 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écrirons ci-dessous comment nous pourrions implémenter certaines de ces fonctionnalités à l'aide de MVC.

entrez la description de l'image ici

Model-View-Presenter

  • Le modèle est les données qui seront affichées dans la vue (interface utilisateur).
  • La vue est une interface qui affiche les données (le modèle) et achemine les commandes utilisateur (événements) vers le présentateur pour agir sur ces données. La vue fait généralement référence à son présentateur.
  • Le présentateur est le «middle-man» (joué par le contrôleur dans MVC) et a des références à la fois à la vue et au modèle. Veuillez noter que le mot «modèle» est trompeur. Il devrait plutôt s'agir d'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, alors le présentateur aura une référence à la logique métier de votre base de données (comme un DAO) d'où le présentateur interrogera une liste d'utilisateurs.

Si vous voulez voir un exemple avec une implémentation simple, veuillez consulter ce post GitHub

Un workflow concret d'interrogation et d'affichage d'une liste d'utilisateurs à partir d'une base de données pourrait fonctionner comme ceci: entrez la description de l'image ici

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

Modèle MVC

  • Le contrôleur est basé sur les comportements et peut être partagé entre les vues

  • Peut être chargé de déterminer la vue à afficher (modèle de contrôleur avant)

Modèle MVP

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

  • Test unitaire plus facile car l'interaction avec la vue se fait via une interface

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

Rahul
la source
2
non, il n'y a pas de connexion directe entre la vue et le modèle en mvc. votre diagramme est faux.
Özgür
33

Il convient également de rappeler qu'il existe également différents types de MVP. Fowler a divisé le modèle en deux: vue passive et contrôleur superviseur.

Lorsque vous utilisez la vue passive, votre vue implémente généralement une interface à grain fin avec des propriétés mappant plus ou moins directement au widget d'interface utilisateur sous-jacent. Par exemple, vous pourriez avoir une ICustomerView avec des propriétés telles que le nom et l'adresse.

Votre implémentation pourrait ressembler à ceci:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Votre classe de présentateur parlera au modèle et le "mappera" à la vue. Cette approche est appelée «vue passive». L'avantage est que la vue est facile à tester, et il est plus facile de se déplacer entre les plates-formes d'interface utilisateur (Web, Windows / XAML, etc.). L'inconvénient est que vous ne pouvez pas tirer parti de choses comme la liaison de données (qui est vraiment puissante dans des cadres comme WPF et Silverlight ).

La deuxième version de MVP est le contrôleur superviseur. Dans ce cas, votre vue peut avoir une propriété appelée Customer, qui est à nouveau liée aux widgets de l'interface utilisateur. Vous n'avez pas à penser à la synchronisation et à la micro-gestion de la vue, et le contrôleur superviseur peut intervenir et vous aider en cas de besoin, par exemple avec une logique d'interaction compliquée.

La troisième "saveur" de MVP (ou quelqu'un l'appellerait peut-être un modèle distinct) est le modèle de présentation (ou parfois appelé Model-View-ViewModel). Comparé au MVP, vous "fusionnez" le M et le P en une seule classe. Vous avez votre objet client auquel vos widgets d'interface utilisateur sont liés aux données, mais vous avez également des champs spécifiques à l'interface utilisateur comme "IsButtonEnabled", ou "IsReadOnly", etc.

Je pense que la meilleure ressource que j'ai trouvée pour l'architecture de l'interface utilisateur est la série de billets de blog rédigés par Jeremy Miller sur la table des matières de la série Build Your Own CAB . Il a couvert toutes les saveurs de MVP et a montré le code C # pour les implémenter.

J'ai également blogué sur le modèle Model-View-ViewModel dans le contexte de Silverlight sur YouCard Re-visité: Implémentation du modèle ViewModel .

Jonas Follesø
la source
25

Ils abordent chacun des problèmes différents et peuvent même être combinés ensemble pour avoir quelque chose comme ci-dessous

Le motif combiné

Il y a aussi une comparaison complète de MVC, MVP et MVVM ici

Xiaoguo Ge
la source
1
Au lieu de trop compliquer les choses, vous auriez pu répondre à la question. C'est pourquoi la majorité d'entre nous sommes ici. Vous avez cherché une comparaison entre mvp et mvc et vous avez été redirigé ici et vous parlez de l'harmonie de ces architectures qui n'est pas liée à OP.
Farid
18

Ces deux cadres visent à séparer les préoccupations - par exemple, l'interaction avec une source de données (modèle), la logique d'application (ou la transformation de ces données en informations utiles) (contrôleur / présentateur) et le code d'affichage (vue). 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 ici concernant les différences entre MVC et MVP.

La distinction faite est que dans une application MVC, la vue et le contrôleur interagissent traditionnellement 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 un cadre MVP parce que le contrôleur accède au modèle pour remplir la vue qui est censée n'avoir aucune logique (affiche simplement les variables fournies par le contrôleur).

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

Matt Mitchell
la source
7
MVC et MVP sont des modèles, pas des cadres. Si vous pensez honnêtement, ce sujet concernait le framework .NET, alors c'est comme entendre "Internet" et penser qu'il s'agit d'IE.
tereško
Je suis presque sûr que la question a évolué de manière significative depuis sa première question en 2008. De plus, en repensant à ma réponse (et c'était il y a 4 ans, je n'ai pas beaucoup plus de contexte que vous), je dirais que je commence généralement et utilisez ensuite .NET MVC comme exemple concret.
Matt Mitchell
13

Les deux sont des modèles essayant de séparer la présentation et la logique métier, découplant 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 dans le cycle de vie de page de formulaire Web standard MVP est simplement amélioré en extrayant la logique métier du code derrière. En d'autres termes, la page est celle qui traite la requête http. En d'autres termes, MVP IMHO est un type d'amélioration évolutif sous forme Web. MVC, d'autre part, change complètement le jeu car la demande est interceptée par la classe de 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 transférées sur la page ("voir"). sens, MVC ressemble beaucoup (au moins pour moi) à la saveur du contrôleur superviseur de MVP amélioré avec le moteur de routage

Les deux activent TDD et ont des inconvénients et des avantages.

La décision sur la façon de choisir l'un d'entre eux à mon humble avis devrait être basée sur le temps investi dans le type de développement Web ASP NET. Si l'on se considérait bon dans les formulaires Web, je suggérerais MVP. Si l'on ne se sentait pas aussi à l'aise dans des choses comme le cycle de vie des pages, etc. MVC pourrait être un moyen d'aller ici.

Voici encore un autre lien de billet 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

Nikola Malovic
la source
9

J'ai utilisé à la fois MVP et MVC et bien que nous, en tant que développeurs, ayons tendance à nous concentrer sur les différences techniques des deux modèles, le point pour MVP dans IMHO est beaucoup plus lié à la facilité d'adoption qu'autre chose.

Si je travaille dans une équipe qui a déjà une bonne expérience du style de développement de formulaires Web, il est beaucoup plus facile d'introduire MVP que MVC. Je dirais que MVP dans ce scénario est une victoire rapide.

Mon expérience me dit que déplacer une équipe de formulaires Web vers MVP puis de MVP vers MVC est relativement facile; passer des formulaires Web à MVC est plus difficile.

Je laisse ici un lien vers une série d'articles qu'un de mes amis a publiés sur MVP et MVC.

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

Pedro Santos
la source
8

Dans MVP, la vue tire 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 tire les données du modèle et de l'ensemble, en poussant la vue.

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

MVP utilise généralement une sorte de cadre de liaison, tel que le cadre de liaison Microsoft WPF ou divers cadres de liaison pour HTML5 et Java.

Dans ces cadres, l'interface utilisateur / HTML5 / XAML est consciente de la propriété du présentateur que chaque élément d'interface utilisateur affiche, donc lorsque vous liez une vue à un présentateur, la vue recherche les propriétés et sait comment en tirer des données et comment 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, expose les propriétés de la voiture (année, fabricant, sièges, etc.) à la vue. La vue sait que le champ de texte appelé «constructeur automobile» 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 - cela peut être un avion, un train ou quoi que ce soit, la vue ne se soucie pas. La vue tire des données du présentateur - peu importe qui - tant qu'elle met en œuvre une interface convenue.

Ce cadre de liaison, si vous le supprimez, c'est en fait le contrôleur :-)

Et donc, 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 par vue. 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 vous avez besoin du contrôleur A pour recevoir un objet avec une interface - qui est comme MVP uniquement sans les liaisons, ou vous devez réécrire le code de l'ensemble d'interface utilisateur dans le contrôleur B.

Conclusion - MVP et MVC sont tous deux découplés des modèles d'interface utilisateur, mais MVP utilise généralement un cadre de liaisons qui est MVC en dessous. AINSI MVP est à un niveau architectural plus élevé que MVC et un modèle de wrapper au-dessus de MVC.

James Roeiter
la source
6

Mon humble vision: MVP est pour les grandes échelles et MVC pour les petites échelles. Avec MVC, j'ai parfois l'impression que le V et le C peuvent être vus des deux côtés d'un seul composant indivisible plutôt directement lié à M, et on y tombe inévitablement lorsque l'on descend à des échelles plus courtes, comme les contrôles d'interface utilisateur et les widgets de base. À ce niveau de granularité, MVP n'a guère de sens. Au contraire, lorsque l'on va à des échelles plus grandes, une interface appropriée devient plus importante, la même chose avec une attribution sans équivoque des responsabilités, et voici MVP.

En revanche, cette règle d'échelle empirique peut peser très peu lorsque les caractéristiques de la plate-forme favorisent une sorte de relations entre les composants, comme avec le Web, où il semble plus facile d'implémenter MVC, plus que MVP.

Hibou57
la source
4

Je pense que cette image d'Erwin Vandervalk (et l' article qui l'accompagne ) est 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.

image expliquant MVC, MVP et MVVM - par Erwin Vandervalk

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

Jboy Flaga
la source
3

Il existe de nombreuses versions de MVC, cette réponse concerne le MVC d'origine dans Smalltalk. Bref, c'est image de mvc vs mvp

Cette conversation droidcon NYC 2017 - La conception d'une application propre avec des composants d'architecture le clarifie

entrez la description de l'image ici entrez la description de l'image ici

onmyway133
la source
6
Dans le MVC, le modèle n'est jamais appelé directement depuis la vue
rodi
5
Ceci est une réponse inexacte. Ne vous trompez pas. comme l'écrit @rodi, il n'y a pas d'interaction entre la vue et le modèle.
Shawn Mehan
L'image MVC est inexacte ou au mieux trompeuse, veuillez ne pas prêter attention à cette réponse.
Jay
2
@ Jay1b Quel MVC pensez-vous est "correct"? Cette réponse concerne le MVC d'origine. Il y a beaucoup d'autres MVC (comme dans iOS) qui ont été modifiés pour s'adapter à la plate-forme, disons commeUIKit
onmyway133
Que signifient les flèches?
problemofficer
3

Il y a cette belle vidéo d'oncle Bob où il explique brièvement MVC et MVP à la fin.

IMO, MVP est une version améliorée de MVC où vous séparez fondamentalement le souci de ce que vous allez montrer (les données) de la façon dont vous allez montrer (la vue). Le présentateur inclut un peu la logique métier de votre interface utilisateur, impose implicitement quelles données doivent être présentées et vous donne une liste de modèles de vues stupides. Et lorsque vient le temps d'afficher les données, il vous suffit de brancher votre vue (qui inclut probablement les mêmes identifiants) dans votre adaptateur et de définir les champs de vue pertinents à l'aide de ces modèles de vue avec une quantité minimale de code introduite (en utilisant uniquement des paramètres). Son principal avantage est que vous pouvez tester votre logique métier d'interface utilisateur par rapport à de nombreuses / diverses vues, comme l'affichage des éléments dans une liste horizontale ou verticale.

Dans MVC, nous parlons à travers des interfaces (frontières) pour coller différentes couches. Un contrôleur est un plug-in de notre architecture, mais il n'a pas une telle restriction pour imposer quoi montrer. En ce sens, MVP est une sorte de MVC avec un concept de vues pouvant être connectées au contrôleur via des adaptateurs.

J'espère que cela aide mieux.

stdout
la source
2
Point important d'oncle Bob: Lorsqu'il a été inventé à l'origine par Trygve Reenskaug, MVC était destiné à chaque widget et non à la forme entière.
Basil Bourque
2

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

Comme expliqué dans certains graphiques ci-dessus, il existe une relation / lien direct 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 oublient toujours 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 90 ". MVC n'a pas été créé à l'origine pour le Web, mais pour les applications de bureau à la place, où le contrôleur , Model et View coexisteraient ensemble.

Parce que nous utilisons des frameworks web ( par exemple: Laravel ) qui utilisent toujours les mêmes conventions de nommage ( model-view-controller ), nous avons tendance à penser que ce doit être MVC, mais c'est en fait autre chose.

Au lieu de cela, jetez un œil à Action-Domain-Responder . Dans ADR, le contrôleur obtient une action , qui effectuera une opération dans le modèle / domaine . Jusqu'à présent, la même chose. La différence est qu'il collecte ensuite les réponses / données de cette opération et les 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 l'ADR, il n'y a pas de connexion entre le modèle / domaine et la vue ( réponse du reponseur ).

Remarque: Wikipedia indique que " Chaque action ADR, cependant, est représentée par des classes ou fermetures distinctes. ". 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.

Hugo Rafael Azevedo
la source
2

La réponse la plus simple est de savoir comment la vue interagit avec le modèle. Dans MVP, la vue est mise à jour par le présentateur, qui sert d'intermédiaire entre la vue et le modèle. Le présentateur prend l'entrée de la vue, qui récupère les données du modèle, puis exécute toute logique métier requise, puis met à jour la vue. Dans MVC, le modèle met à jour la vue directement plutôt que de revenir via le contrôleur.

Clive Jefferies
la source
J'ai rétrogradé, car afaik le modèle ne sait rien de la vue dans MVC et il n'est pas possible de la mettre à jour directement pendant que vous écrivez.
problemofficer
1
Regardez MVC sur Wikipédia, c'est exactement comme cela que ça fonctionne.
Clive Jefferies
1
Que les lecteurs le veuillent ou non, de nombreuses sources qui peuvent être trouvées en recherchant sur Google indiquent que dans MVC, la vue souscrit aux mises à jour sur le modèle. et dans certains cas, pourrait même être le contrôleur et donc invoquer de telles mises à jour. Si vous n'aimez pas cela, allez vous plaindre de ces articles, ou citez la «bible» que vous pensez être la seule source légitime, au lieu de diminuer les réponses qui relaient simplement les autres informations disponibles!
underscore_d
1
Le libellé pourrait certainement être amélioré, mais il est vrai que la vue souscrit aux modifications du modèle dans MVC. Le modèle n'a pas besoin de connaître la vue dans MVC.
dévoré elysium le
merci .. Cela m'a beaucoup aidé
Dvyn Resh
1
  • Dans MVC, View a la partie UI, le contrôleur est le médiateur entre la vue et le modèle et le modèle contient la logique métier.
  • Dans MVP, View contient à la fois l'interface utilisateur et l'implémentation du présentateur, car ici le présentateur n'est qu'une interface et le modèle est le même, c'est-à-dire qu'il contient la logique métier.
Chinmai Kulkarni
la source
-1

MVP

MVP signifie Model - View- Presenter. Cela est venu à une image au début de 2007 où Microsoft a présenté des applications Windows Smart Client.

Un présentateur joue un rôle de supervision dans MVP qui lie les événements de visualisation et la logique métier à partir de modèles.

La liaison d'événement de vue sera implémentée dans le présentateur à partir d'une interface de vue.

La vue est l'initiateur des entrées utilisateur, puis délègue les événements au présentateur et le présentateur gère les liaisons d'événements et obtient les données des modèles.

Avantages: La vue n'a que l'interface utilisateur, pas de logique Niveau de testabilité élevé

Inconvénients: peu complexe et plus de travail lors de la mise en œuvre des liaisons d'événements

MVC

MVC signifie Model-View-Controller. Le contrôleur est responsable de la création de modèles et du rendu des vues avec des modèles de liaison.

Le contrôleur est l'initiateur et il décide quelle vue rendre.

Avantages: Accent sur le principe de responsabilité unique Niveau élevé de testabilité

Inconvénients: Parfois, trop de charge de travail pour les contrôleurs, si vous essayez de rendre plusieurs vues dans le même contrôleur.

marvelTracker
la source