Modèle–vue–présentateur

Le modèle-vue-présentateur ( MVP ) est une dérivation du modèle-vue-contrôleur (MVC) et est principalement utilisé pour créer des interfaces utilisateur.

Dans MVP, le présentateur assume la fonction d'« intermédiaire ». Dans MVP, toute la logique de présentation est transmise au présentateur.

Le modèle logiciel modèle-vue-présentateur a été créé au début des années 1990 chez Taligent , une coentreprise d' Apple , d'IBM et de Hewlett-Packard . MVP est le modèle de programmation sous-jacent pour le développement d'applications dans l' environnement CommonPoint basé sur C++ de Taligent . Le modèle a ensuite été migré par Taligent vers Java et popularisé dans un article du directeur technique de Taligent, Mike Potel.

Après l'arrêt de Taligent en 1998, Andy Bower et Blair McGlashan de Dolphin Smalltalk ont ​​adapté le modèle MVP pour former la base de leur infrastructure d'interface utilisateur Smalltalk. En 2006, Microsoft a commencé à incorporer MVP dans sa documentation et ses exemples de programmation d'interface utilisateur dans le .NET Framework .

L'évolution et les multiples variantes du modèle MVP, y compris la relation du MVP avec d'autres modèles de conception tels que MVC, sont discutées en détail dans un article de Martin Fowler et un autre de Derek Greer.

MVP est un modèle d'architecture d'interface utilisateur conçu pour faciliter les tests unitaires automatisés et améliorer la séparation des préoccupations dans la logique de présentation :

• Le modèle est une interface définissant les données à afficher ou à traiter d'une autre manière dans l'interface utilisateur.
• La vue est une interface passive 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.
• Le présentateur agit sur le modèle et la vue. Il récupère les données des référentiels (le modèle) et les formate pour les afficher dans la vue.

Normalement, l'implémentation de la vue instancie l'objet présentateur concret, en fournissant une référence à lui-même. Le code C# suivant illustre un constructeur de vue simple :

classe publique Présentateur : IPresenter { public Présentateur ( vue IView ) { // ... } }
classe publique View : IView { privé IPresenter _presenter ;
public View () { _presenter = nouveau Présentateur ( ceci ); } }

Le degré de logique autorisé dans la vue varie selon les différentes implémentations. À un extrême, la vue est entièrement passive, transmettant toutes les opérations d'interaction au présentateur. Dans cette formulation, lorsqu'un utilisateur déclenche une méthode d'événement de la vue, il ne fait rien d'autre qu'invoquer une méthode du présentateur qui n'a pas de paramètres et pas de valeur de retour. Le présentateur récupère ensuite les données de la vue via des méthodes définies par l'interface de la vue. Enfin, le présentateur opère sur le modèle et met à jour la vue avec les résultats de l'opération. D'autres versions de modèle–vue–présentateur permettent une certaine latitude quant à la classe qui gère une interaction, un événement ou une commande particulière. Cela est souvent plus adapté aux architectures Web, où la vue, qui s'exécute sur le navigateur d'un client, peut être le meilleur endroit pour gérer une interaction ou une commande particulière.

D'un point de vue de superposition, la classe présentateur peut être considérée comme appartenant à la couche application dans un système d'architecture multicouche , mais elle peut également être considérée comme une couche présentatrice à part entière entre la couche application et la couche d'interface utilisateur .

L' environnement .NET prend en charge le modèle MVP comme tout autre environnement de développement. Le même modèle et la même classe de présentateur peuvent être utilisés pour prendre en charge plusieurs interfaces, telles qu'une application Web ASP.NET ou une application Windows Forms . Le présentateur obtient et définit des informations depuis/vers la vue via une interface accessible par le composant d'interface (vue).

En plus de l’implémentation manuelle du modèle, un framework modèle-vue-présentateur peut être utilisé pour prendre en charge le modèle MVP de manière plus automatisée.

Dans une application Java ( AWT / Swing / SWT ), le modèle MVP peut être utilisé en laissant la classe d'interface utilisateur implémenter une interface de vue.

La même approche peut être utilisée pour les applications Web Java, car les frameworks Web modernes basés sur des composants Java permettent le développement de la logique côté client en utilisant la même approche de composants que les clients lourds.

L'implémentation de MVP dans Google Web Toolkit nécessite uniquement que certains composants implémentent l'interface d'affichage. La même approche est possible en utilisant Vaadin ou le framework Web Echo2 .

Les frameworks Java incluent les éléments suivants :

• JavaFX
• Echo2
• Boîte à outils Web de Google
• JFace
• Balançoire
• Vaadin
• ZK

Grâce à l' environnement d'exécution flexible de PHP , il existe de nombreuses possibilités d'approches de la logique d'une application. La mise en œuvre de la couche modèle est laissée à la charge du programmeur d'application final.

Les frameworks PHP incluent les éléments suivants :

• CodeIgniter
• Laravel
• Cadre Nette