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

Question

Quand on regarde au-delà du RAD (glisser-déposer et configurer) pour créer des interfaces utilisateur que de nombreux outils vous encouragent. Vous rencontrerez probablement trois modèles de conception appelés Modèle Vue Contrôleur, Modèle-Vue-Présentateur et Modèle-Vue-VueModèle.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?

Answer 1

Modèle-Vue-Présentateur

Dans MVP, le présentateur contient la logique métier de l'interface utilisateur pour la vue.Tous les appels du délégué View directement au présentateur.Le Présentateur est également découplé directement de la Vue et lui parle via une interface.Ceci permet de se moquer de la vue dans un test unitaire.Un attribut commun du 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.Tu peux en savoir plus sur les deux variantes.

Deux variantes principales

Vue passive : La vue est aussi stupide que possible et ne contient presque aucune logique.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 s'y abonne 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 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
• Escroquer:plus de travail (par exemple toutes les propriétés du setter) car vous effectuez vous-même toutes les liaisons de données.

Contrôleur superviseur : Le présentateur gère les gestes de l'utilisateur.La vue se lie au modèle directement via la liaison de données.Dans ce cas, c'est le travail du présentateur de transmettre 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, la navigation, etc.

• Pro:en tirant parti de la liaison de données, la quantité de code est réduite.
• Escroquer:il y a moins de surface testable (en raison de la liaison de données) et il y a moins d'encapsulation dans la vue puisqu'elle communique directement avec le modèle.

Modèle Vue Contrôleur

Dans le MVC, le contrôleur est chargé de déterminer quelle vue afficher en réponse à toute action, y compris lors du chargement de l'application.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 ainsi qu'une action.Sur le Web, chaque action implique un appel à une URL de l'autre côté de laquelle se trouve un contrôleur qui répond.Une fois que ce contrôleur a terminé son traitement, il renverra la vue correcte.La séquence se poursuit ainsi 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 avec 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'aura généralement aucune logique dans le code sous-jacent.Ceci est contraire à MVP où c'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 à examiner est le Modèle de présentation 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 des propriétés que l'on ne mettrait jamais sur 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-behind, 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é Modèle-Vue-VueModèle.

Il y a un Article MSDN sur le modèle de présentation et une section dans le Guide d’application composite pour WPF (ancien Prism) à propos Modèles de présentation séparés

Answer 2

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

MVC

MVP

Answer 3

J'ai blogué à ce sujet il y a quelque temps, citant L'excellent article 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.
• Test unitaire plus facile car l'interaction avec la vue se fait via une interface
• Habituellement, visualisez la carte du présentateur en tête-à-tête.Des vues complexes peuvent avoir plusieurs présentateurs.

Modèle MVC

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

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

Answer 4

Voici des illustrations qui représentent le flux de communication

Answer 5

MVP est pas forcément un scénario où la Vue est aux commandes (voir le MVP de Taligent par exemple).
Je trouve dommage que les gens prêchent encore cela comme un modèle (View in charge) par opposition à un anti-modèle car cela contredit "C'est juste un point de vue" (Pragmatic Programmer)."C'est juste une vue" indique que la vue finale présenté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 commodément excuse le concepteur de Microsoft d'encourager les mauvaises pratiques.

Pour être tout à fait franc, je pense que les préoccupations sous-jacentes de MVC s'appliquent à toute implémentation de MVP et que 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 de l'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, qui se soucie vraiment de savoir si votre modèle est MVC, MVP ou Supervising Controller ?Le seul réel Le modèle reste MVC, le reste n’en est que des saveurs différentes.

Considérer ce article très passionnant qui répertorie de manière exhaustive un certain nombre de ces différentes implémentations.Vous remarquerez peut-être 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 soit pour réduire les disputes entre bigots sémantiques qui se demandent si quelque chose est vraiment MVC ou non, soit pour justifier les outils de développement rapide d'applications de Microsoft.Aucune de ces raisons évoquées dans mes livres ne justifie son existence en tant que modèle de conception distinct.

Answer 6

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 interagira parfois avec le présentateur, généralement via une interface.Cela se résume à 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.La vue délègue au présentateur.

MVC :le contrôleur est responsable.

Le contrôleur est créé ou accessible en fonction d'un événement/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.

Answer 7

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 elle peut également provenir de la simple saisie d’une URL spécifique dans un navigateur.Dans les deux cas, il s’agit d’un contrôleur avec lequel il est interfacé 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 allant du contrôleur à la vue.En effet, la vue n’a aucune connaissance ni référence au contrôleur.Le contrôleur renvoie le modèle, donc il y a des connaissances entre la vue et le modèle attendu qui y sont transmis, mais pas le contrôleur qui les sert.

MVP (présentateur de vue de modèle)

L'entrée commence par la vue, pas par 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, il est donc conscient 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 ne prend pas en compte le modèle.

Pour plus Référence

Answer 8

Il existe de nombreuses réponses à la question, mais j'ai senti qu'il était nécessaire d'avoir une réponse très simple comparant clairement les deux.Voici la discussion que j'ai créée lorsqu'un utilisateur recherche un nom de film dans une application MVP et MVC :

Utilisateur:Cliquez cliquez…

Voir:Qui c'est?[MVP|MVC]

Utilisateur:Je viens de cliquer sur le bouton recherche...

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

( Voir appeler le Présentateur|Manette … ) [MVP|MVC]

Voir:Hé Présentateur|Manette, un Utilisateur vient de cliquer sur le bouton de recherche, que dois-je faire ?[MVP|MVC]

Présentateur|Manette:Hé Voir, y a-t-il un terme de recherche sur cette page ?[MVP|MVC]

Voir:Oui,… le voici… « piano » [MVP|MVC]

Présentateur:Merci Voir,… pendant ce temps, je recherche le terme de recherche sur le Modèle, veuillez lui montrer une barre de progression [MVP|MVC]

( Présentateur|Manette appelle le Modèle … ) [MVP|MVC]

Présentateur|Manette:Hé Modèle, Avez-vous une correspondance pour ce terme de recherche ? :« piano » [MVP|MVC]

Modèle:Hé Présentateur|Manette, laisse moi vérifier … [MVP|MVC]

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

( Après un certain temps ...)

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

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

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

(Présentateur|Manette merci Modèle et revient au Voir) [MVP|MVC]

Présentateur:Merci pour votre patience Voir, j'ai trouvé pour vous une liste de résultats correspondants et je les ai organisés dans un format présentable :["Professeur de piano 2001", "Piano 1993"].Veuillez le montrer à l'utilisateur dans une liste verticale.Veuillez également masquer la barre de progression maintenant [MVP]

Manette:Merci pour votre patience Voir, J'ai demandé Modèle à propos de votre requête de recherche.Il indique avoir trouvé une liste de résultats correspondants et les avoir 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]

Voir:Merci "Contrôleur" [MVC] (Maintenant le Voir se remet en question :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-il être dans une liste verticale ou horizontale ?...)

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

Answer 9

• MVP = Modèle-Vue-Présentateur

• MVC = Modèle-Vue-Contrôleur

  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 la façon dont votre interface utilisateur est censée se comporter (présentateur/contrôleur)
  2. Leur concept est assez similaire, les gens initialisent le présentateur/contrôleur différemment selon leurs goûts.
  3. Un excellent article sur les différences est ici.Le plus remarquable est que le modèle MVC permet au modèle de mettre à jour la vue.

Answer 10

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 de supervision.

Lorsque vous utilisez la vue passive, votre vue implémente généralement une interface à granularité fine avec des propriétés mappées plus ou moins directement au widget d'interface utilisateur sous-jacent.Par exemple, vous pourriez avoir un ICustomerView avec des propriétés telles que Nom et Adresse.

Votre implémentation pourrait ressembler à ceci :

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

Votre classe Presenter 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 qu'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 exploiter des éléments tels que la liaison de données (qui est vraiment puissant dans des cadres comme WPF et Lumière argentée).

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

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).Par rapport 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 disposez également de champs supplémentaires spécifiques à l'interface utilisateur tels que "IsButtonEnabled" ou "IsReadOnly", etc.

Je pense que la meilleure ressource que j'ai trouvée sur l'architecture de l'interface utilisateur est la série d'articles de blog rédigés par Jeremy Miller sur Table des matières de la série Construisez votre propre CAB.Il a couvert toutes les versions 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 revisitée :Implémentation du modèle ViewModel.

Answer 11

Modèle Vue Contrôleur

MVC est un modèle pour l'architecture d'une application logicielle.Il sépare la logique de l'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 divise une application en composants suivants :

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

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

Modèle-Vue-Présentateur

• Le modèle sont les données qui seront affichées dans la vue (interface utilisateur).
• Le voir 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 « l’intermédiaire » (joué par le contrôleur dans MVC) et fait référence à la fois à la vue et au modèle. Veuillez noter que le mot « Modèle » est trompeur.Il faudrait plutôt que ce soit 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) à partir de laquelle le présentateur interrogera une liste d'utilisateurs.

Si vous souhaitez voir un exemple avec une implémentation simple, veuillez vérifier ce article 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 :

Quel est le différence entre MVC et MVP motifs?

Modèle MVC

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

• Peut être responsable de la détermination de la 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 lier le modèle à la vue.

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

• Habituellement, visualisez la carte du présentateur en tête-à-tête.Les vues complexes peuvent avoir plusieurs présentateurs.

Answer 12

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

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

Answer 13

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.Un bon exemple en est le Projet de vitrine MVC.

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 selon ces définitions un framework MVP car 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 entre ASP.NET MVC et MVP, consultez cette présentation MIX par Scott Hanselman.

Answer 14

Les deux sont des modèles essayant de séparer la présentation et la logique métier, 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 dans le cycle de vie des pages de formulaire Web standard MVP, il est simplement amélioré en extrayant la logique métier du code sous-jacent.En d’autres termes, la page est celle qui traite la requête http.En d’autres termes, MVP à mon humble avis est un type d’amélioration évolutive de formulaire 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 du contrôleur, les données qui viennent d'être déversées sur la page ("vue") sens, MVC semble (du moins pour moi) beaucoup pour superviser la saveur du contrôleur de MVP amélioré 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, à mon humble avis, devrait être basée sur le temps investi dans le développement Web de type formulaire Web ASP NET.Si l’on se considère bon dans les formulaires Web, je suggérerais MVP.Si l'on ne se sent pas aussi à l'aise avec des choses telles que le cycle de vie des pages, etc., MVC pourrait être une solution ici.

Voici encore un autre lien vers un article 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

Answer 15

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, l'intérêt de MVP à mon humble avis est beaucoup plus lié à la facilité d'adoption qu'à toute autre chose.

Si je travaille dans une équipe qui possède déjà une bonne expérience en matière de 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 des formulaires Web vers MVP puis de MVP vers MVC est relativement simple ;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

Answer 16

Dans MVP, la vue extrait les données du présentateur qui extrait 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 les insérant dans la vue.

Dans MVP, vous pouvez avoir une seule vue travaillant avec plusieurs types de présentateurs et un seul présentateur 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 frameworks, l'UI/HTML5/XAML connaît la propriété du présentateur que chaque élément de l'interface utilisateur affiche. Ainsi, 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, alors le présentateur est une sorte de présentateur de voiture, exposant 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 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 - il peut s'agir d'un avion, d'un train ou autre, la vue s'en fiche.La vue extrait les données du présentateur - quel qu'il soit - à condition qu'elle implémente une interface convenue.

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

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

MVC est génial, mais le problème est que son contrôleur est généralement 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 que le contrôleur A connaisse le modèle B, ou vous avez besoin que le contrôleur A reçoive un objet avec une interface - qui est comme MVP uniquement sans les liaisons, ou vous devez réécrire le code défini par l'interface utilisateur dans le contrôleur B.

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

Answer 17

Mon humble avis:MVP est destiné aux grandes échelles et MVC aux petites échelles.Avec MVC, j'ai parfois l'impression que le V et le C peuvent être vus comme les deux faces d'un seul composant indivisible plutôt directement lié à M, et on y tombe inévitablement en descendant à 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, lorsqu'on va à plus grande échelle, une bonne interface devient plus importante, de même avec une attribution sans ambiguïté des responsabilités, et voici MVP.

D'un autre côté, cette règle d'échelle empirique peut avoir très peu d'importance lorsque les caractéristiques de la plate-forme favorisent une certaine sorte de relations entre les composants, comme avec le Web, où il semble plus facile d'implémenter MVC que MVP.

Answer 18

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

OMI, MVP est une version améliorée de MVC dans laquelle vous séparez essentiellement la préoccupation de ce que vous allez afficher (les données) de la façon dont vous allez afficher (la vue).Presenter inclut en quelque sorte 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 vue stupides.Et lorsque vient le temps d'afficher les données, il vous suffit de brancher votre vue (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 simplement des setters).Son principal avantage est que vous pouvez tester la logique métier de votre 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 (limites) pour coller différentes couches.Le contrôleur est un plug-in de notre architecture mais il n'a pas de restriction pour imposer ce qu'il doit afficher.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.

Answer 19

Il existe de nombreuses versions de MVC, cette réponse concerne le MVC original dans Smalltalk.Bref, c'est

Cette conversation droidcon NYC 2017 - Conception d'applications épurée avec des composants d'architecture le clarifie

Answer 20

La réponse la plus simple est de savoir comment la vue interagit avec le modèle.Dans MVP, la vue est liée au présentateur, qui agit comme intermédiaire entre la vue et le modèle, prenant les entrées de la vue, obtenant les données du modèle, puis exécutant une logique métier et enfin mettant à jour la vue.Dans MVC, le modèle met à jour la vue directement plutôt que de revenir via le contrôleur.

Answer 21

Je pense que cette image d'Erwin Vandervalk (et l'illustration qui l'accompagne) article) est la meilleure explication de MVC, MVP et MVVM, de leurs similitudes et de leurs différences.Le 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.

(Le article Cela 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)

Answer 22

MVP

MVP signifie Modèle - Vue - Présentateur.Cela s'est produit au début de 2007, lorsque Microsoft a introduit les applications Windows Smart Client.

Le présentateur joue un rôle de supervision dans MVP qui lie les événements View et les logiques métier des modèles.

La liaison d’événement View sera implémentée dans Presenter à partir d’une interface d’affichage.

View 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 récupère les données des modèles.

Avantages:La vue n'a que l'interface utilisateur et pas de logiques élevés de testabilité

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

MVC

MVC signifie Modèle-Vue-Contrôleur.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:Imphase sur le principe de responsabilité unique Haut-niveau de testabilité

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