Introduction
MVP, tirant son nom de l'abréviation de l'anglicisme Model-View-Presenter, est un pattern d'architecture logicielle utilisé pour structurer des applications avec interface utilisateur, surtout lorsqu'on veut séparer la logique de présentation de la logique métier et faciliter les tests unitaires. Le sigle signifie :
- Model : le modèle, représentant les données et la logique métier.
- View : la vue, responsable de l'affichage et de l'interface utilisateur.
- Presenter : le présentateur, qui contient la logique de présentation et agit comme intermédiaire entre la vue et le modèle.
Contrairement à MVC, où le contrôleur peut réagir directement aux événements de l'UI, dans MVP, la vue est passive et délègue toute action au Presenter.
Composantes détaillés
- Model : Contient les données et la logique métier. Peut inclure des services, des bases de données, ou des API. Indépendant de la vue et du presenter, comme dans MVC/MVVM.
- View : Affiche les données et capte les actions de l'utilisateur (clics, saisie,...). Ne contient aucune logique de traitement, elle transmet seulement les événements au Presenter. Implémente souvent une interface qui définit ce que le Presenter peut manipuler ou modifier dans la vue.
- Presenter : Sert de pont entre le Model et la View. Contient la logique de présentation : quelles données afficher, comment répondre aux actions de l'utilisateur, mise à jour de la vue. Interroge le Model et envoie les résultats à la View. Comme la View est passive, le Presenter peut être testé indépendamment.
Fonctionnement
L'utilisateur interagit avec la View (exemple clic sur un bouton).
La View informe le Presenter de l'action.
Le Presenter interagit avec le Model, récupère ou met à jour les données.
Le Presenter met à jour la View avec les nouvelles données ou états.
Diagramme simplifié :
La flèche bidirectionnelle View ↔ Presenter correspond aux événements et mises à jour.
La flèche Presenter ↔ Model correspond à la récupération ou modification des données.
Avantages
Séparation stricte des responsabilités → code plus maintenable.
Testabilité élevée → le Presenter peut être testé sans la vue réelle.
Réutilisation possible → un Presenter peut servir plusieurs vues.
Vue passive → réduit le couplage et simplifie l'UI.
Exemple
Voici un exemple simple en C# (WinForms) :
- // Model
- public class Utilisateur
- {
- public string Nom { get; set; }
- public string Prenom { get; set; }
- }
-
- // View Interface
- public interface IUtilisateurView
- {
- string NomComplet { set; }
- event EventHandler ClicAfficher;
- }
-
- // Presenter
- public class UtilisateurPresenter
- {
- private readonly IUtilisateurView _view;
- private readonly Utilisateur _utilisateur;
-
- public UtilisateurPresenter(IUtilisateurView view)
- {
- _view = view;
- _utilisateur = new Utilisateur { Prenom = "Jean", Nom = "Dupont" };
- _view.ClicAfficher += OnClicAfficher;
- }
-
- private void OnClicAfficher(object sender, EventArgs e)
- {
- _view.NomComplet = $"{_utilisateur.Prenom} {_utilisateur.Nom}";
- }
- }