Quelqu'un peut-il expliquer d'une manière aussi simple que possible ce qu'est le pattern Model View Presenter ? Quelle est la différence avec Model View Controller ? Lequel est le meilleur ou à quelle fin ?
Model View Presenter et Model View Controller tentent tous deux de résoudre le même problème de "séparation des préoccupations".
La principale différence réside dans le fait que le MVC (Model View Controller) est souvent mis en œuvre avec un certain couplage entre la vue et un modèle quelconque - ainsi, une vue donnée est spécifiquement destinée à fournir une visualisation d'un objet donné (modèle).
Dans le modèle Model View Presenter, c'est généralement le Presenter qui se charge de travailler avec le modèle et de décider des informations dont il aura besoin pour former une sorte de visualisation.
Dans ce diagramme, les flèches représentent des dépendances :
Généralement, on entend parler de ce modèle lorsqu'on évoque le cadre ASP.NET MVC, et on tombe sur des informations concernant le modèle MVP et sa mise en œuvre dans ASP.NET WebForms. D'après mon expérience, il est fréquent que l'on pense que WebForms est en soi un framework MVP - ce n'est pas vrai. WebForms permet cependant de mettre en œuvre très facilement un modèle MVP - votre meilleure ressource pour cela serait d'étudier le Web Client Software Factory de l'équipe Patterns and Practices :
Site de CodePlex : http://www.codeplex.com/websf
Un excellent screencast couvrant le sujet : http://www.pnpguidance.net/Screencast/MVPBundleScreencastWCSFModelViewPresenterDesignPattern.aspx
Je ne suis pas sûr que ces flèches de dépendance soient bonnes. En MVC, pourquoi la vue dépend-elle du modèle ?
Ce n'est certainement pas le cas. ont mais il s'agit de l'implémentation la plus courante. Par exemple, si vous utilisez ASP.NET MVC, la meilleure pratique consiste à rendre votre "vue" dépendante d'un type (en créant une vue fortement typée). Les implémentations MVC typiques envoient un modèle à une vue, puis laissent la vue décider de ce qu'il faut en faire (créant ainsi une dépendance), alors que dans MVP, la vue demandera littéralement au présentateur "Quelles données dois-je mettre dans cette zone de texte ?".
Martin Fowler a une page sur les modèles de conception d'interface utilisateur, dans laquelle il définit et parle ensuite de MVC, MVP et autres modèles.
http://martinfowler.com/eaaDev/uiArchs.html
Pour résumer les différences, les contrôleurs dans le MVC ont plus de contrôle sur l'interface utilisateur et gèrent les événements, tandis qu'un présentateur dans le MVP est plus passif et se contente de présenter les informations via l'interface utilisateur.
En général, il n'y a pas beaucoup de différence, et la frontière entre les deux est souvent floue.
Fowler sépare le MVP en 2 modèles : Le présentateur superviseur et le spectateur passif.
Aviad Ezra a un bon article sur ce sujet. http://aviadezra.blogspot.com/2008/10/model-view-presenter-design-pattern.html .
Je pense que MVP est mieux pour les ordinateurs de bureau, et MVC pour les applications web, parce que dans les ordinateurs de bureau, le modèle a la capacité d'élever l'événement.
L'article d'Aviad Ezra cité en référence m'a été très utile pour commencer à utiliser le modèle architectural MVP dans mon application de bureau WinForms. Le code d'exemple inclus est facile à comprendre.
Dolphin Smalltalk avait une implémentation MVC mais ils ont ensuite migré vers MVP.
Voici le document technique qui décrit ce qu'ils ont fait et pourquoi : http://www.object-arts.com/downloads/papers/TwistingTheTriad.PDF
Le système Taligent d'IBM a également utilisé MVP - ils décrivent ici ce qu'ils font et pourquoi : http://www.wildcrest.com/Potel/Portfolio/mvp.pdf
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
