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


En regardant au-delà de la RAD (glisser-déposer et configurer) façon de construire des interfaces utilisateur que de nombreux outils vous encouragent sont susceptibles de rencontrer trois modèles de conception appelés Modèle Vue Contrôleur, Model-View-Presenter et Model-View-ViewModel. Ma question comporte trois parties:

  1. À quels problèmes ces modèles répondent-ils?
  2. Comment sont-ils similaires?
  3. Comment sont-ils différents?

1834
2017-08-05 10:06


origine


Réponses:


Model-View-Presenter

Dans MVP, le présentateur contient la logique métier de l'interface utilisateur pour la vue. Toutes les invocations de la vue sont déléguées directement à Presenter. Le Presenter 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 de MVP est qu'il doit y avoir beaucoup de dispatching bidirectionnel. Par exemple, lorsqu'un utilisateur 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 rappelle 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 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 variations primaires

Vue passive: La vue est aussi bête 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 s'y abonne pour la mise à jour de la vue. En mode passif, il n'y a pas de liaison de données directe, mais la vue expose les propriétés du setter utilisées par le présentateur 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 propre de la vue et du modèle
  • Con: plus de travail (par exemple toutes les propriétés du setter) car vous faites vous-même toutes les données.

Contrôleur de supervision: Le Presenter gère les mouvements de l'utilisateur. La vue se lie directement au modèle via la liaison de données. Dans ce cas, le présentateur doit passer 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 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 puisqu'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 à une action, y compris lorsque l'application charge. Cela diffère de MVP où les actions passent par la vue au présentateur. Dans MVC, chaque action dans la vue est corrélée 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 retourne la vue correcte. La séquence continue 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 rend simplement, et est complètement apatride. Dans les implémentations de MVC, la vue n'a généralement aucune logique dans le code derrière. Ceci est contraire à MVP où c'est absolument nécessaire parce que, 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é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 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 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 à 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 des commandes que la vue utilise pour invoquer des actions. L'avantage de cette approche est que vous pouvez essentiellement supprimer le code-behind tout comme 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 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 de Modèles de présentation séparés


1796
2017-08-05 10:21



J'ai blogué à ce sujet il y a un certain temps, citant sur L'excellent article de Todd Snyder sur la différence entre les deux:

Voici les principales différences entre   les motifs:

MVP Pattern

  • La vue est plus faiblement couplée au modèle. Le présentateur est   responsable de lier le modèle à   la vue.
  • Plus facile à l'unité de test parce que l'interaction avec la vue est à travers   une interface
  • Habituellement voir au présentateur carte une à une. Les vues complexes peuvent avoir   multi-présentateurs.

MVC Pattern

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

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


384
2017-07-06 22:18



Ceci est 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

MVC

MVP

enter image description here


367
2017-09-12 20:47



Voici des illustrations qui représentent le flux de communication

enter image description here 

enter image description here


208
2017-08-25 21:22



MVP est ne pas nécessairement un scénario où la Vue est en charge (voir le MVP de Taligent par exemple).
Je trouve malheureux que les gens prêchent encore cela comme un modèle (View in charge) par opposition à un anti-pattern car il contredit "C'est juste une vue" (Pragmatic Programmer). "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 commodément 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 de l'utilisateur) et le modèle (les données et / ou services sous-jacents), alors vous obtenez les avantages de MVC . Si vous obtenez les avantages alors qui se soucie vraiment si votre modèle est MVC, MVP ou contrôleur de supervision? Le seul réal Le motif reste MVC, les autres ne sont que des arômes différents.

Considérer ce article très excitant qui énumère de manière exhaustive un certain nombre de ces différentes implémentations. Vous remarquerez qu'ils font tous fondamentalement la même chose, mais légèrement différemment.

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


148
2017-08-06 22:51



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 l'affichage appelle des méthodes sur le présentateur ou voulez-vous que la vue affiche des événements auxquels 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 accédé 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 l'esclave du contrôleur. La vue ne connaît pas le contrôleur.


90
2017-12-20 02:10



enter image description here

MVC (contrôleur de vue de modèle)

L'entrée est d'abord dirigée vers le contrôleur, pas la vue. Cette entrée peut provenir d'un utilisateur interagissant avec une page, mais cela peut aussi être 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 à afficher en fonction de l'opération en cours d'exécution. Notez la flèche à sens unique de Controller à View. C'est parce que la vue n'a aucune connaissance ou référence au contrôleur. Le contrôleur renvoie le modèle, il existe donc des connaissances entre la vue et le modèle attendu, mais pas le contrôleur qui le sert.

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

L'entrée commence par la vue et non 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, de sorte qu'il est conscient de la vue à laquelle il est associé. 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 prise en compte par le modèle.

Pour plus Référence


62
2017-08-05 10:22



  • MVP = Model-View-Presenter
  • 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 manière dont votre interface utilisateur est censée se comporter (Presenter / Controller)
    2. Ils sont assez semblables dans le concept, les gens initialisent le présentateur / contrôleur différemment selon le goût.
    3. Un bon article sur les différences est ici. Le plus remarquable est que le modèle MVC a le modèle mettant à jour la vue.

31
2017-08-08 05:55



Il convient également de se rappeler qu'il existe 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 correspondant plus ou moins directement au widget de l'interface utilisateur sous-jacente. Par exemple, vous pourriez avoir un ICustomerView avec des propriétés comme le nom et l'adresse.

Votre implémentation peut ressembler à ceci:

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

Votre classe Presenter va parler au modèle et le "mapper" à la vue. Cette approche est appelée la "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 tirer parti de choses comme la liaison de données (qui est vraiment puissant dans des cadres comme WPF et Silverlight).

La deuxième saveur de MVP est le contrôleur superviseur. Dans ce cas, votre View peut avoir une propriété appelée Customer, qui est à nouveau liée aux 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 aider lorsque cela est nécessaire, par exemple avec une logique d'interaction complétée.

La troisième "saveur" de MVP (ou quelqu'un l'appellerait peut-être un modèle séparé) est le modèle de présentation (ou parfois référé à Model-View-ViewModel). Comparé au MVP, vous "fusionnez" le M et le P en une classe. Vous avez votre objet client auquel sont liés vos widgets d'interface utilisateur, mais vous disposez également de champs supplémentaires spécifiques à l'interface utilisateur, tels que "IsButtonEnabled", "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 faite par Jeremy Miller à La table des matières Build Your Own de la série 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 au YouCard revisité: Implémentation du pattern ViewModel.


31
2018-04-06 13:51



Il y a beaucoup de réponses à la question, mais j'ai senti qu'il y avait un besoin pour 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 sur ...

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

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

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

( Vue appeler le Présentateur|Manette ...) [MVP|MVC]

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

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

Vue: Oui, ... le voici ... "piano" [MVP|MVC]

Présentateur: Merci Vue, ... 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]

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

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

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

( Modèle fait une requête à la base de données de film ...) [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, ici c'est dans JSON "[{" name ":" Piano Teacher "," année ": 2001}, {" name ":" Piano "," année ": 1993}]" [MVP]

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

(Présentateur|Manette Merci Modèle et revient à la Vue) [MVP|MVC]

Présentateur: Merci pour votre patience Vue, 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]

Manette: Merci pour votre patience Vue, J'ai demandé Modèle à propos de 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" dans son instance. Vous pouvez l'obtenir à partir de là. Veuillez également masquer la barre de progression maintenant [MVC]

Vue: Merci beaucoup Présentateur [MVP]

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

Au cas où vous seriez intéressé, j'ai écrit une série d'articles traitant de modèles architecturaux d'application (MVC, MVP, MVVP, architecture propre, ...) accompagnés d'un dépôt Github ici. Même si l'échantillon est écrit pour Android, les principes sous-jacents peuvent être appliqués à tout support.


17
2017-08-05 10:20



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 en transformant ces données en informations utiles) (Controller / Presenter) 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. Un bon exemple de ceci est le Projet MVC Storefront.

Il y a une discussion ici concernant les différences entre MVC vs MVP.

La distinction faite est que dans une application MVC a traditionnellement la vue et le contrôleur interagissent avec le modèle, mais pas les uns avec les autres.

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

Cela dit, ASP.NET MVC est par ces définitions une structure 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 par Scott Hanselman.


15
2018-03-13 05:54