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

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?

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

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

MVP

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.

Voici des illustrations qui représentent le flux de communication

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.

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.

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

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.

• 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.

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.

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:

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.

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 .

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

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

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.

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

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

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.

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.

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.

(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)

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

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

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.

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.

mvc adr Modèle Vue Contrôleur répondeur-domaine-action

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.

• 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.

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.