web-dev-qa-db-fra.com

Quelles sont les améliorations de MVP par rapport à MVC?

J'ai lu pendant trois jours les modèles Model-View-Controller (MVC) et Model-View-Presenter (MVP) . Et il y a une question qui me dérange beaucoup. Pourquoi les concepteurs de logiciels ont-ils inventé le MVP, alors qu'il existait déjà un MVC?

Quels problèmes ont-ils rencontrés, que MVC n'a pas résolus (ou mal résolus), mais que MVP peut résoudre? Quels problèmes MVP est-il censé résoudre?

J'ai lu beaucoup d'articles sur l'histoire et l'explication de MVP, ou sur les différences entre MVC et MVP, mais aucun n'avait de réponse claire à mes questions.

Dans l'un des articles que j'ai lu, il était dit:

Passons maintenant à Model View Presenter, qui était une réponse aux insuffisances du modèle MVC lorsqu'il était appliqué aux interfaces utilisateur graphiques basées sur des composants modernes. Dans les systèmes GUI modernes, les composants GUI eux-mêmes gèrent les entrées utilisateur telles que les mouvements de souris et les clics, plutôt que certains contrôleurs centraux.

Donc, je ne peux pas comprendre, mais cela peut-il en fait être d'une autre manière, de sorte que les composants GUI ne gèrent pas les entrées utilisateur par eux-mêmes? Et que signifie exactement "gérer par eux-mêmes"?

designdesign-patternsmvcmvp
50
Victor

MVC est conceptuellement élégant:

  • l'entrée utilisateur est gérée par le contrôleur
  • le contrôleur met à jour le modèle
  • le modèle met à jour la vue/l'interface utilisateur
           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

Cependant: le flux de données et d'événements dans MVC est circulaire. Et la vue contient souvent une logique importante (comme les gestionnaires d'événements pour les actions des utilisateurs). Ensemble, ces propriétés rendent le système difficile à tester et difficile à entretenir.

L'architecture MVP remplace le contrôleur par un présentateur, qui sert de médiateur entre la vue et le modèle. Cela linéarise le système:

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

Cela présente les avantages suivants:

  • La logique (comme les gestionnaires d'événements et l'état de l'interface utilisateur) peut être déplacée de la vue vers le présentateur.

  • L'interface utilisateur peut être testée unitaire en termes de présentateur, car elle décrit l'état de l'interface utilisateur. À l'intérieur du test unitaire, nous remplaçons la vue par un pilote de test qui appelle le présentateur.

  • L'interface utilisateur étant isolée de la logique d'application, les deux peuvent être développées indépendamment.

Mais cette approche présente également certains inconvénients:

  • Cela demande plus d'efforts.
  • Le présentateur peut facilement muter en une "classe divine" incontrôlable.
  • L'application n'a pas un seul axe MVP, mais plusieurs axes: un pour chaque écran/fenêtre/panneau dans l'interface utilisateur. Cela peut soit simplifier votre architecture, soit la rendre excessivement compliquée.
64
amon

Dans MVP, le présentateur remplace le contrôleur de MVC. La différence entre les deux est que le présentateur manipule directement la vue. Il est conçu pour les frameworks d'interface utilisateur qui sont principalement pilotés par les événements (comme Windows Forms) sans prise en charge intensive de la liaison de données riches qui se prêtent au modèle MVVM (comme WPF). Sinon, une grande partie de la logique de gestion de l'état de la vue et de mise à jour du modèle de support se trouverait dans la vue elle-même.

6
Michael Brown