Looking for ios Keywords? Try Ask4Keywords

iOSArchitecture MVP


Introduction

MVP est un modèle architectural, une dérivation du modèle – View – Controller. Il est représenté par trois composants distincts: Modèle, Vue et Présentateur. Il a été conçu pour faciliter les tests unitaires automatisés et améliorer la séparation des problèmes dans la logique de présentation.

Dans des exemples, vous trouverez un projet simple conçu en fonction du modèle MVP.

Remarques

Composants:

entrer la description de l'image ici

  • Le modèle est une interface responsable des données du domaine (à afficher ou à utiliser dans l'interface graphique)
  • View est responsable de la couche de présentation (GUI)
  • Le présentateur est le "intermédiaire" entre le modèle et la vue. Il réagit aux actions de l'utilisateur effectuées sur la vue, récupère les données du modèle et les formate pour les afficher dans la vue.

Devoir du composant:

Modèle Vue Présentateur
Communique avec le calque DB Rend les données Effectue des requêtes sur le modèle
Élever des événements appropriés Reçoit des événements Données de format du modèle
Logique de validation très basique Envoie des données formatées à la vue
Logique de validation complexe

Différences entre MVC et MVP :

  • View in MVC est étroitement lié au Controller, la partie View du MVP comprend à la fois UIViews et UIViewController
  • MVP View est aussi stupide que possible et ne contient pratiquement aucune logique (comme dans MVVM), MVC View possède une certaine logique métier et peut interroger le modèle
  • MVP View gère les gestes des utilisateurs et délègue les interactions au présentateur, dans MVC, le contrôleur gère les gestes et les commandes du modèle.
  • Le modèle MVP supporte fortement les tests unitaires, MVC a un support limité
  • MVC Controller a beaucoup de dépendances UIKit, MVP Presenter n'en a pas

Avantages:

  • MVP fait de UIViewController une partie du composant View, il est stupide, passif et moins massif;]
  • La plupart de la logique métier est encapsulée en raison des vues stupides, ce qui donne une excellente testabilité. Des objets simulés peuvent être introduits pour tester la partie domaine.
  • Les entités séparées sont plus faciles à garder en tête, les responsabilités sont clairement divisées.

Les inconvénients

  • Vous allez écrire plus de code.
  • Barrière pour les développeurs inexpérimentés ou pour ceux qui ne travaillent pas encore avec le modèle.

Architecture MVP Exemples Liés