Quels sont les MVP et MVC et quelle est la différence?

voix
1k

Lorsque l'on regarde 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 venir à travers trois modèles de conception appelé Model-View-Controller , Model-View-Presenter et Model-View-ViewModel . Ma question comporte trois parties à elle:

  1. Quels problèmes ces modèles traitent?
  2. Comment sont-ils semblables?
  3. Comment sont-ils différents?
Créé 05/08/2008 à 11:06
source utilisateur
Dans d'autres langues...                            


25 réponses

voix
1k

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é Voir directement à Presenter. Le présentateur est également découplé directement à partir de la vue et parle à travers une interface. Cela permet moqueur de la vue dans un test unitaire. Un attribut commun de MVP est qu'il doit y avoir beaucoup de dispatching dans les deux sens. Par exemple, lorsque quelqu'un clique sur le bouton « Enregistrer », les délégués de gestionnaires d'événements à la méthode « OnSave » du présentateur. Une fois la sauvegarde terminée, le présentateur sera ensuite rappellerons la vue à travers son interface afin que la vue peut afficher que la sauvegarde est terminée.

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

Deux principales variations

Voir le passif: Le point de vue est aussi stupide que possible et contient presque zéro logique. Le présentateur est un homme du milieu qui parle à la vue et le modèle. La vue et le modèle sont complètement protégés les uns des autres. Le modèle peut déclencher des événements, mais le présentateur est abonnée à les mettre à jour la vue. Dans la vue Passive il n'y a pas de données liaison directe, au lieu de la vue expose les propriétés setter que le présentateur utilise pour définir les données. Tout état est géré dans le présentateur et non la vue.

  • Pro: surface de testabilité maximale; séparation propre de la vue et le modèle
  • Con: plus de travail (par exemple toutes les propriétés setter) que vous faites toutes les données vous-même liaison.

Contrôleur de supervision: Le présentateur gère les gestes de l' utilisateur. La vue se lie au modèle directement par liaison de données. Dans ce cas , il est le travail du présentateur de faire passer le modèle à la vue afin qu'il puisse se lier à elle. Le présentateur contiendra également la logique des gestes comme appuyer sur un bouton, la navigation, etc.

  • Pro: en tirant parti databinding la quantité de code est réduit.
  • 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'il parle directement au modèle.

Modèle Vue Contrôleur

Dans le MVC , le contrôleur est chargé de déterminer qui View pour afficher en réponse à toute action , y compris lors du chargement de l' application. Cela diffère de MVP où la route des actions à travers la vue du présentateur. Dans MVC, chaque action dans la vue en corrélation avec un appel à un contrôleur avec une action. Dans le web chaque action implique un appel à une URL de l'autre côté duquel se trouve un contrôleur qui répond. Une fois que le contrôleur a terminé son traitement, il retournera la vue correcte. La séquence se poursuit de cette manière pendant toute la durée de l'application:

    Action dans la vue
        -> Appel au contrôleur
        -> Contrôleur logique
        -> Controller retourne la vue.

Une autre grande différence à propos de MVC est que la vue ne lie pas directement au modèle. La vue rend tout simplement, et est tout à fait sans état. Dans les implémentations de MVC la vue généralement pas logique dans le code sous-jacent. Cela est contraire à MVP où il est absolument nécessaire car, si la vue ne délègue pas au présentateur, il ne sera jamais appelé.

présentation Modèle

Un autre motif à regarder est le modèle de présentationmodèle. Dans ce modèle il n'y a pas Presenter. Au lieu de cela la vue se lie directement à un modèle de présentation. La présentation est un modèle conçu spécifiquement pour la vue. Cela signifie que ce modèle peut exposer les propriétés que l'on aurait jamais mis sur un modèle de domaine que ce serait une violation de séparation des-préoccupations. Dans ce cas, la présentation modèle se fixe au modèle de domaine et peut souscrire à des événements à venir de ce modèle. La vue souscrit ensuite à des événements à venir du modèle de présentation et se met à jour en conséquence. Le modèle de présentation peut exposer les commandes qui utilise la vue pour invoquer des actions. L'avantage de cette approche est que vous pouvez essentiellement supprimer le code-behind tout à fait que le PM encapsule complètement l'ensemble du comportement pour la vue.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 (ex - Prisme) sur les modèles de présentation Séparées

Créé 19/09/2008 à 13:46
source utilisateur

voix
381

Je blogué sur ce un moment, citant le poste de Todd Snyder excellente sur la différence entre les deux :

Voici les principales différences entre les modèles:

Motif MVP

  • La vue est plus lâchement couplé au modèle. Le présentateur est responsable de la liaison du modèle à la vue.
  • Plus facile à tester l'unité parce que l'interaction avec la vue est à travers une interface
  • voir habituellement à la carte du présentateur un à un. vues complexes peuvent avoir plusieurs présentateurs.

modèle MVC

  • Controller sont basés sur les comportements et peuvent être partagées entre vues
  • Peut être chargé de déterminer quelle vue afficher

Il est la meilleure explication sur le web que je pouvais trouver.

Créé 05/08/2008 à 11:21
source utilisateur

voix
358

Ceci est une simplification excessive des nombreuses variantes de ces modèles de conception, mais voilà comment je me plais à penser sur les différences entre les deux.

MVC

MVC

MVP

entrez la description d'image ici

Créé 06/07/2013 à 23:18
source utilisateur

voix
202

Voici les illustrations qui représentent le flux de communication

entrez la description d'image ici

entrez la description d'image ici

Créé 12/09/2014 à 21:47
source utilisateur

voix
147

MVP est pas nécessairement un scénario où la vue est en charge (voir MVP de Taligent par exemple).
Je trouve malheureux que les gens prêchent encore cela comme un motif (Voir en charge) par opposition à un anti-modèle car elle contredit « Il est juste une vue » (Pragmatic Programmer). « Il est juste une vue » indique que la vue finale montre à 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 facilement des excuses de concepteur de Microsoft d'encourager les mauvaises pratiques.

Pour être tout à fait franc, je pense que les préoccupations sous - jacentes de MVC sont valables pour tout et la mise en œuvre MVP les différences sont presque entièrement sémantique. Tant que vous suivez la séparation des préoccupations entre le point de 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 sous - jacentes et / ou services)) alors vous acheiving les avantages de MVC . Si vous acheiving les avantages alors qui se soucie vraiment de savoir si votre modèle est MVC, MVP ou contrôleur de supervision? Le seul vrai modèle reste que MVC, les autres sont juste différentes saveurs de celui - ci.

Considérez cet article très intéressant qui répertorie globalement un certain nombre de ces implémentations différentes. Vous pouvez constater qu'ils font tous essentiellement la même chose , mais un peu différemment.

Personnellement, je pense MVP n'a été récemment réintroduite comme un terme accrocheur soit de réduire les arguments entre bigots sémantiques qui prétendent que quelque chose est vraiment MVC ou non ou pour justifier Microsofts Outils de développement d'application rapide. Aucune de ces raisons dans mes livres justifie son existence en tant que modèle de conception distincte.

Créé 25/08/2008 à 22:22
source utilisateur

voix
85

MVP: la vue est en charge.

La vue, dans la plupart des cas, crée son présentateur. Le présentateur va interagir avec le modèle et manipuler la vue à travers une interface. La vue parfois interagir avec le présentateur, généralement par une interface. Cela revient à la mise en œuvre; Voulez-vous le point de vue d'appeler des méthodes sur le présentateur ou voulez-vous la vue d'organiser des événements le présentateur écoute à? Il se résume à ceci: La vue sait sur le présentateur. Les délégués ont vue sur le présentateur.

MVC: le contrôleur est en charge.

Le contrôleur est créé ou accessible sur la base d'un événement / demande. Le contrôleur crée alors la vue appropriée et interagit avec le modèle pour configurer davantage la vue. Il se résume à: le contrôleur crée et gère la vue; la vue est esclave de l'automate. La vue ne connaît pas le contrôleur.

Créé 06/08/2008 à 23:51
source utilisateur

voix
58

entrez la description d'image ici

MVC (Model View Controller)

L'entrée est dirigée vers le contrôleur de premier, pas la vue. Cette entrée vient peut-être d'un utilisateur d'interagir avec une page, mais il pourrait aussi être simplement d'entrer une URL spécifique dans un navigateur. Dans les deux cas, son un contrôleur qui est interfacé avec le coup d'envoi des fonctionnalités. Il existe une relation many-to-one entre le contrôleur et la vue. En effet, un seul contrôleur peut choisir différentes vues à rendre basé sur l'opération en cours d'exécution. Notez la flèche à sens unique du contrôleur à la vue. En effet, la vue n'a pas de connaissance ou de référence au contrôleur. Le contrôleur ne passe en arrière du modèle, donc il y a des connaissances entre la vue et le modèle attendu étant passé dans, mais pas le contrôleur au service vers le haut.

MVP (Model View Présentateur)

L'entrée commence par la vue, pas le présentateur. Il y a 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 à des événements déclenchés depuis la vue, il est donc au courant de la vue de son associé. Le présentateur met à jour la vue sur la base des actions demandées qu'il effectue sur le modèle, mais la vue est pas aware.

Pour en savoir plus Référence

Créé 20/12/2015 à 02:10
source utilisateur

voix
31

On retiendra aussi est qu'il existe différents types de MVPs aussi bien. Fowler a cassé le modèle en deux - Voir le passif et le contrôleur de supervision.

Lorsque vous utilisez View passif, votre vue de mettre en œuvre généralement plus ou moins directement une interface à grains fins avec la cartographie des propriétés du widget UI underlaying. Par exemple, vous pourriez avoir un ICustomerView avec des propriétés comme le nom et adresse.

Votre mise en œuvre pourrait ressembler à ceci:

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

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

La deuxième saveur de MVP est le contrôleur de supervision. Dans ce cas, votre vue pourrait avoir une propriété appelée client, puis est à nouveau DataBound aux widgets de l'interface utilisateur. Vous ne devez pas penser à la synchronisation et la micro-gestion de la vue, et le contrôleur de supervision peut intervenir et aider en cas de besoin, par exemple avec une logique d'interaction compled.

Le troisième « saveur » de MVP (ou quelqu'un peut appeler un modèle distinct) est le modèle de présentation (ou parfois appelé Model-View-ViewModel). Par rapport au MVP vous « fusionner » M et P dans une classe. Vous avez votre objet client que vos widgets de l'interface utilisateur est lié aux données, mais vous avez également des champs de l'interface utilisateur-spesific supplémentaires comme « IsButtonEnabled » ou « IsReadOnly », etc.

Je pense que la meilleure que j'ai trouvé à l' architecture de l' interface utilisateur est la série de messages de blog fait par Jeremy Miller sur au BUILD votre propre table Série CAB des matières . Il couvre toutes les saveurs de MVP et a montré le code C # pour les mettre en œuvre.

J'ai aussi blogué sur le modèle Model-View-ViewModel dans le contexte de Silverlight sur au YouCard revisité: Mise en œuvre du modèle ViewModel .

Créé 08/08/2008 à 06:55
source utilisateur

voix
31
  • 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 des objets de domaine), votre écran / page Web (la vue), et comment votre interface utilisateur est censé se comporter (Présentateur / contrôleur)
    2. Ils sont assez similaires dans leur concept, les gens initialize le présentateur / contrôleur différemment selon le goût.
    3. Un grand article sur les différences est ici . Le plus remarquable est que le modèle MVC a le modèle de mise à jour de la vue.
Créé 05/08/2008 à 11:22
source utilisateur

voix
15

Ces deux cadres ont pour but de séparer les préoccupations - par exemple, l' interaction avec une source de données (modèle), la logique d'application (ou transformer ces données en informations utiles) (Controller / Présentateur) et le code d'affichage (View). Dans certains cas , le modèle peut également être utilisé pour transformer une source de données dans une abstraction de plus haut niveau aussi bien. Un bon exemple est le projet MVC Storefront .

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

La distinction est que dans une application MVC a toujours la vue et le contrôleur interagir avec le modèle, mais pas avec l'autre.

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

Cela dit, ASP.NET MVC est par ces définitions un cadre MVP car le contrôleur accède au modèle pour remplir la vue qui est censé avoir aucune logique (affiche uniquement 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.

Créé 05/08/2008 à 11:20
source utilisateur

voix
12

Les deux sont des modèles tentent de séparer la présentation et la logique métier, le découplage logique métier des aspects de l'interface utilisateur

Architecturalement, MVP est la page approche basée sur un contrôleur où MVC est approche basée sur Front Controller. Cela signifie que dans le cycle de vie de page du formulaire Web standard MVP est tout simplement améliorée par extraction de la logique métier de code sous-jacent. En d'autres termes, la page est une demande de service http. En d'autres termes, à mon humble avis MVP est la forme de web type d'amélioration de l'évolution. MVC sur d'autre part change complètement le jeu parce que la demande s'intercepté par classe de contrôleur avant page est chargée, la logique métier est exécutée là-bas et puis au résultat final du contrôleur traitement des données simplement sous-évaluées à la page ( « vue ») Dans ce sens, apparence MVC (au moins pour moi) un lot à saveur de contrôleur de supervision de MVP amélioré avec le moteur de routage

Les deux d'entre elles permettent TDD et ont des inconvénients et upsides.

Décision sur la façon de choisir l'un d'entre eux à mon humble avis devrait être basé sur combien de temps investi dans un type de formulaire Web ASP NET de développement web. Si l'on veut se considérer comme bonne dans les formulaires Web, je suggère MVP. Si l'on se sentirait pas à l'aise dans des choses telles que le cycle de vie de la page etc MVC pourrait être un moyen d'aller ici.

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

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

Créé 21/09/2008 à 13:32
source utilisateur

voix
11

Chacun d'eux traite 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

Créé 13/03/2017 à 05:54
source utilisateur

voix
9

Quelque chose que je ne comprends pas pourquoi la liaison de données a pour réduire testabilité. Je veux dire, une vue est basée efficacement hors de ce qui pourrait être considéré comme une ou plusieurs vues de base de données, droit? Il pourrait y avoir des liens entre les lignes des différentes vues. Nous pouvons également parler orienté objet au lieu de relationnel, mais cela ne change rien en fait - nous avons encore une ou plusieurs entités de données distinctes.

Si nous considérons la programmation comme structures de données + algorithmes, alors ne serait-il préférable d'avoir les structures de données explicites que possible, puis de développer des algorithmes que chaque dépendent en tant que petit un morceau de données que possible, avec un couplage minimal entre les algorithmes ?

Je sens très Java-esque modes de pensée FactoryFactoryFactory ici - nous voulons avoir des vues multiples, plusieurs modèles, plusieurs degrés de liberté dans tous les sens. Il est presque comme c'est la force motrice derrière MVC et MVP et ainsi de suite. Maintenant , permettez - moi de poser cette question: comment est souvent le coût que vous payez pour cela (et il y a certainement est un coût) vaut la peine?

Je vois aussi aucune discussion sur la façon de gérer efficacement l'état entre les requêtes HTTP. Avons-nous vraiment appris des gens fonctionnels (et les erreurs volumineuses faites par spaghetti impératif) que l'Etat est mal et doit être réduite au minimum (et quand il est utilisé, doit être bien entendu)?

Je vois beaucoup d'utilisation des termes MVC et MVP sans beaucoup de preuves que les gens pensent de façon critique à leur sujet. De toute évidence, le problème est « eux », moi, ou les deux ...

Créé 28/01/2009 à 22:11
source utilisateur

voix
8

Il y a beaucoup de réponses à la question, mais je sentais qu'il est nécessaire pour une réponse très simple à comparer clairement les deux. Voici la discussion que j'ai fait quand 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 clique sur le bouton de recherche ...

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

( Voir appelant le présentateur | Controller ...) [ MVP | MVC ]

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

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

Voir : Oui, ... voilà ... « piano » [ MVP | MVC ]

Présentateur : Merci Voir , ... Pendant ce temps , je suis à la recherche le terme de recherche sur le modèle , s'il vous plaît lui montrer / elle une barre de progression [ MVP | MVC ]

( Présentateur | Controller appelle le modèle ...) [ MVP | MVC ]

Présentateur | Contrôleur : Hey Modèle , Avez - vous un match pour ce terme de recherche ?: « piano » [ MVP | MVC ]

Modèle : Hey Présentateur | Contrôleur , permettez - moi de 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à commencent à diverger MVP et MVC ---------------

Modèle : J'ai trouvé une liste pour vous, présentateur , ici il est en JSON « [{ "name": "Pianiste", "année": 2001}, { "name": "Piano", "année": 1993} ] »[ MVP ]

Modèle : Il y a un certain résultat disponible, contrôleur . J'ai créé une variable de champ dans mon exemple et rempli du résultat. Son nom est « searchResultsList » [ MVC ]

( Présentateur | Controller merci modèle et revient à la Vue ) [ MVP | MVC ]

Présentateur : Merci d'avoir patienté Voir , j'ai trouvé une liste de résultats correspondants pour vous et les rangeait dans un format présentable: [ « Professeur de piano 2001 », « Piano 1993 »]. S'il vous plaît montrer à l'utilisateur dans une liste verticale. S'il vous plaît également cacher la barre de progression maintenant [ MVP ]

Contrôleur : Merci d'avoir patienté Voir , j'ai demandé Modèle de votre requête de recherche. Il dit qu'il a trouvé une liste de résultats correspondant et les a stockés dans une variable appelée « searchResultsList » dans son instance. Vous pouvez l' obtenir à partir de là. S'il vous plaît également cacher la barre de progression maintenant [ MVC ]

Voir : Merci Présentateur [ MVP ]

Vue : Merci « Controller » [ MVC ] (Maintenant , la vue est lui - même remet en question: Comment dois - je présenter les résultats que je reçois du modèle ? À l'utilisateur Si l'année de production du film arrivé , premier ou dernier ... Faut - il? dans une liste verticale ou horizontale? ...)

Si vous êtes intéressé, je suis en train d' écrire une série d'articles traitant des applications modèles d' architecture (MVC, MVP, MVVP, architecture propre, ...) accompagné d'une prise en pension Github ici . Même si l'échantillon est écrit pour Android, les principes sous - jacents peuvent être appliqués à tout support.

Créé 06/04/2018 à 13:51
source utilisateur

voix
8

Dans Android il y a version de mvc qui est mvp: Qu'est-ce que MVP?

Le motif MVP permet de séparer la couche de présentation de la logique, de sorte que tout sur la façon dont fonctionne l'interface est séparée de la façon dont nous représentons à l'écran. Idéalement, le modèle MVP réaliserait cette même logique pourrait avoir des vues complètement différentes et interchangeables.

La première chose à préciser est que MVP n'est pas un modèle architectural, il est seul responsable de la couche de présentation. En tout cas, il est toujours préférable de l'utiliser pour votre architecture qui ne l'utilisez pas du tout.

Un exemple pour mvp est https://github.com/antoniolg/androidmvp

Qu'est-ce que MVC? l'architecture MVC est l'un des modèles les plus anciens disponibles pour la réalisation de la séparation des préoccupations. MVC est composé de trois couches, à savoir, Modèle, Vue et Contrôleur.

Classique MVC existait à un moment où chaque contrôle / gadget qui existait dans l'écran était considéré comme stupide et chaque contrôle est associé à son propre contrôleur pour gérer les interactions des utilisateurs qui se produisent sur eux. Donc, si 10 gadgets existent, 10 contrôleurs doivent exister. Dans ce scénario, chaque gadget est compté comme une vue. L'avènement des systèmes Windows GUI changé cette image. La relation de contrôle-contrôleur est devenu obsolète. Les contrôles ont acquis l'intelligence de répondre aux actions initiées par l'utilisateur. Dans le monde Windows, vue est une surface sur laquelle tous les contrôles / gadgets existent, par conséquent, il est nécessaire pour un seul contrôleur. Voir peut recevoir des événements et d'atteindre pour les contrôleurs aident à faire un traitement ultérieur.

Exemple de code pour mvc dans les applications http://androidexample.com/Use_MVC_Pattern_To_Create_Very_Basic_Shopping_Cart__-_Android_Example/index.php?view=article_discription&aid=116&aaid=138

La différence entre les deux est disponible ici http://www.codeproject.com/Articles/288928/Differences-between-MVC-and-MVP-for-Beginners

Depuis mon expérience, vous devez utiliser MVP pour un projet basé sur Android, car il version améliorée du modèle MVC.

Créé 02/07/2016 à 07:15
source utilisateur

voix
8

Je l'ai utilisé à la fois MVP et MVC et bien que nous en tant que développeurs ont tendance à se concentrer sur les différences techniques des deux modèles du point de MVP dans mon humble avis est beaucoup plus lié à la facilité d'adoption que toute autre chose.

Si je travaille dans une équipe qui déjà comme un bon fond sur le Web forme le style de développement, il est beaucoup plus facile d'introduire MVP de MVC. Je dirais que MVP dans ce scénario est une victoire rapide.

Mon expérience me dit que le déplacement d'une équipe de formulaires Web à MVP et MVP de MVC est relativement facile; passant de formulaires Web MVC est plus difficile.

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

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

Créé 02/01/2009 à 11:35
source utilisateur

voix
7

Dans la vue MVP tire les données du présentateur qui dessine et prépare / normalise les données du modèle MVC tandis que dans le contrôleur extrait des données du modèle et défini, par poussée dans la vue.

En MVP, vous pouvez avoir une vue unique de travailler avec plusieurs types de présentateurs et un présentateur travaillant avec différents points de vue multiples.

MVP utilise généralement une sorte d'un cadre contraignant, comme cadre contraignant Microsoft WPF ou différents cadres de liaison pour HTML5 et Java.

Dans ces cadres, l'interface utilisateur / HTML5 / XAML, est conscient de ce que la propriété du présentateur d'affichage de chaque élément de l'interface utilisateur, de sorte que lorsque vous liez en vue d'un présentateur, le point de vue recherche les propriétés et sait comment tirer des données d'eux et comment pour les définir quand 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 d'un présentateur de voiture, expose les propriétés de 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é présentateur Maker.

Vous pouvez ensuite lier à la vue de nombreux types différents de présentateur, doivent tous avoir la propriété Maker - il peut être d'un avion, en train ou ce que jamais, la vue ne se soucie pas. La vue attire les données du présentateur - quel que soit - tant qu'il implémente une interface convenue.

Ce cadre contraignant, si vous dépouillez vers le bas, il est en fait le contrôleur :-)

Ainsi, vous pouvez regarder le MVP comme une évolution du MVC.

MVC est grande, mais le problème est que généralement son contrôleur par vue. Contrôleur A sait comment définir les champs de vue A. Si maintenant, vous voulez que View A pour afficher les données de modèle B, vous avez besoin du contrôleur A savoir le modèle B, ou vous avez besoin du contrôleur A à recevoir un objet avec une interface - qui est comme MVP seulement sans les fixations, ou si vous devez réécrire le code de jeu de l'interface utilisateur dans le contrôleur B.

Conclusion - MVP et MVC sont tous les deux découpler des modèles d'interface utilisateur, mais MVP utilise généralement un cadre de liaisons qui est MVC dessous. AINSI MVP est à un niveau plus élevé que l'architecture MVC et un motif d'enveloppe au-dessus de MVC.

Créé 07/06/2013 à 22:16
source utilisateur

voix
6

Mon humble avis court: MVP est pour les grandes échelles et MVC pour les échelles minuscules. Avec MVC, je me sens parfois le V et le C peut être vu un deux faces d'une seule composante indivisible, directement lié à M, et on tombe inévitablement à ce que l'on descend à des échelles plus courtes, comme les contrôles de l'interface utilisateur et les widgets de base. A ce niveau de granularité, MVP a peu de sens. Quand on au contraire aller à plus grande échelle, l'interface appropriée devient plus importante, la même chose avec des responsabilités affectation claire et vient ici MVP.

D'autre part, cette règle à l'échelle d'un pouce, peut poids très peu lorsque les caractéristiques de la plate-forme favorise une sorte de relations entre les composants, comme avec le web, où il semble être plus facile à mettre en œuvre MVC, plus de MVP.

Créé 20/02/2013 à 17:55
source utilisateur

voix
5

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, la promotion de la modularité et la facilité de collaboration et de réutilisation. Il fait également des applications plus souple et accueillant pour iterations.It une application dans sépare les composants suivants:

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

Pour faire un peu plus clair, imaginons une application simple liste d'achats. Tout ce que nous voulons est une liste du nom, la quantité et le prix de chaque article que nous devons acheter cette semaine. Ci-dessous, nous allons décrire comment nous pourrions mettre en œuvre certaines de ces fonctionnalités en utilisant MVC.

entrez la description d'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 des données (le modèle) et les voies des commandes d'utilisateur (événements) de l'animateur à agir sur ces données. La vue a généralement une référence à son présentateur.
  • Le présentateur est le « middle-man » (joué par le contrôleur dans MVC) et des références à la fois, la vue et le modèle. S'il vous plaît noter que le mot « modèle » est trompeur. Il devrait plutôt 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 votre vue veut afficher une liste d'utilisateurs, le présentateur aurait une référence à votre logique métier de base de données (comme un DAO) d'où le présentateur interroge une liste des utilisateurs.

Si vous voulez voir un échantillon avec la mise en œuvre simple , s'il vous plaît vérifier ce post github

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

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

modèle MVC

  • Controller sont basés sur les comportements et peuvent être partagées entre vues

  • Peut être chargé de déterminer quelle vue d'affichage (modèle Front Controller)

Motif MVP

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

  • Plus facile à tester l'unité parce que l'interaction avec la vue est à travers une interface

  • voir habituellement à la carte du présentateur un à un. vues complexes peuvent avoir plusieurs présentateurs.

Créé 29/11/2017 à 10:14
source utilisateur

voix
3

Il existe plusieurs versions de MVC, cette réponse est sur le MVC original Smalltalk. En bref, il est image de mvc mvp vs

Cette conférence droidcon NYC 2017 - Un design épuré de l' application avec les composants d' architecture clarifie

entrez la description d'image ici entrez la description d'image ici

Créé 09/09/2015 à 02:34
source utilisateur

voix
0

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

Ce que je pense est MVP est une version améliorée de MVC où vous séparer essentiellement le souci de la façon dont vous allez montrer les données que vous avez. Présentateur comprend un peu la logique métier de l'interface utilisateur et parle à travers une interface qui le rend plus facile à tester votre logique métier de l'interface utilisateur dans les différents points de vue. MVC parle encore par des interfaces (limites) aux couches de colle, mais il n'a pas une telle restriction à imposer la logique de présentation de l'interface utilisateur. A part cela, je ne vois vraiment pas plus de différences.

Créé 25/01/2018 à 21:24
source utilisateur

voix
0

MVP

MVP signifie Modèle - Présentateur Affichage-. Cela est arrivé à l'image au début de 2007 où les applications Microsoft introduit Windows Smart Client.

Présentateur agit comme un rôle de supervision dans MVP qui liant Afficher les événements et logiques d'affaires à partir de modèles.

Voir événement de liaison sera mis en œuvre Présentateur d'une interface de visualisation.

Voir est l'initiateur pour les entrées utilisateur et délègue ensuite les événements Présentateur et présentatrice gère les liaisons d'événements et obtenir des données à partir de modèles.

Plus: Voir est d' avoir seulement l' interface utilisateur pas logique haut niveau de testabilité

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 de rendu des vues avec des modèles de fixation.

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

Plus: L' accent sur la responsabilité unique Principe haut niveau de testabilité

Inconvénients: Parfois trop de travail pour les contrôleurs, si essaient de rendre plusieurs vues en même contrôleur.

Créé 12/01/2016 à 04:50
source utilisateur

voix
-1

La réponse la plus simple est de savoir comment la vue interagit avec le modèle. Dans MVP du modèle est lié au présentateur, qui est responsable de la mise à jour de la vue. Dans le modèle MVC met à jour la vue directement.

Créé 16/11/2017 à 17:32
source utilisateur

voix
-2

Ici affiché ci-dessus est un résumé de l'échec de l'homme et de l'incapacité de comprendre la poignée de main plus simple entre les deux machines. Je vais vous expliquer en utilisant le bon sens pour tenter de vous réveiller tout de ces idéalisme délirant qui ont trouvé leur chemin dans l'esprit de ceux qui souhaitent les créer. Et aussi fou que tous ces processus son, fait est le modèle d'objet (qui est le fichier HTML) est demandée par la machine cliente. Voici comment tout cela se résume.

  1. Un lien hypertexte est pressé et une seule demande est envoyée par la machine du client au serveur. Le serveur répond à cette demande avec une réponse en envoyant le modèle d'objet au client. (Connu simplement comme une « réponse »).
  2. Le serveur répond en envoyant un modèle d'objet (le fichier HTML) à la machine Clients (Connu comme Handshake pleine).
  3. Le navigateur client peut maintenant rendu la « vue » par l'analyse syntaxique, lexing / tokenizing et la conversion de ce modèle objet Markup dans une interface graphique « View ».

Je peux être à la retraite maintenant, mais ça alors les gars ici plaidons et débattre une absurdité totale. Et honnêtement, peu importe ce que vous appelez une poignée de main entre deux machines ne peut pas être quelque chose en dehors d'une seule demande, une seule réponse de l'objet « Modèle » et enfin le navigateur Clients rendu la « vue ».

Et en terminant, une vue n'existe pas dans une poignée de main. Le modèle d'objet est uniquement de balisage pour le navigateur pour convertir GUI Sets Widget et méthodes Eval par trois ou plusieurs modèles d'objets. HTML, CSS et JavaScript. Et peu importe combien quelqu'un peut dire un serveur fait quelque chose hors de l'ordinaire est à cheval Dung.

Le « serveur » est pas la réponse « Controller » est un Directer et dirige uniquement la réponse en envoyant un objet « Modèle ». Le navigateur du client (ce qui serait le contrôleur probable) crée alors le « View » de l'objet « Modèle » le serveur n'a rien à voir avec cela. Votre langage informatique ne peut pas entrer dans l'objet du modèle du tout, ni déléguer. Tout ce qu'il est est un balisage Créateur.

Le désordre entier est tout simplement un navigateur côté client « contrôleur » qui analyse le « modèle » pour rendre le « View » ou CMV ou VCM (envoyé comme modèle dans le premier ordre) et vous ne peux pas le changer. Mais vous pouvez l'appeler simplement une demande, réponse Object Model et Rendu de la vue ou RRMV.

Créé 31/12/2018 à 02:10
source utilisateur

voix
-2

Beaucoup de gens ne savent pas exactement quelle est la différence entre le contrôleur et présentateur dans MVC et MVP respectivement.

son une équation simple où

MVC View = Vue et présentateur de MVP

MVP Modèle = contrôleur et le modèle de MVC

plus d' informations reportez - vous à ce http://includeblogh.blogspot.com.eg/2016/07/the-difference-and-relationship-between.html

Créé 31/07/2017 à 10:13
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more