MVP In Silverlight/WPF Series. Nederlandstalig? U woont in Vlaanderen? Bezoek Vlakbij.me en kom in contact met de beste handelaars in je buurt I recently criticized the MVVM pattern which pretty much every Silverlight and WPF developer has probably used by now. Reactions to that post were (as was to be expected) pretty varied. And that's why I decided to write this series instead of simply trying to back up my statements with a post that showed some code. These are the posts the series consists of: Modèle de conception MVPVM – Le modèle de conception MVPVM (Model-View-Presenter-ViewModel, Modèle-Vue-Présentation-Modèle de Vue) pour WPF. De tous les projets couronnés de succès auxquels j'ai participé, les plus réussis partagent un résultat commun : à mesure que l'application grandissait, le codebase devenait plus petit.
De prime abord, cela peut sembler contradictoire, mais le codage dans un environnement Agile se prête à une réduction du codebase. Lorsque les exigences changent, il se produit une refactorisation et cette opportunité de refactorisation, associée à du recul, offre la capacité de réutiliser les composants existants plus efficacement tout en éliminant le code doublon du processus.
À l'inverse, j'ai rencontré des projets monolithiques, qui ont été considérés comme réussis, dans lesquels le code source devenait de plus en plus important avec une faible possibilité de réutilisation. Ces projets ont commencé à consommer beaucoup de ressources et sont devenus un risque pour la croissance future. Quelle était la différence fondamentale ? Le modèle de conception de l'infrastructure utilisé. Le modèle MVC. Presentation Model. Represent the state and behavior of the presentation independently of the GUI controls used in the interface Also Known As: Application Model GUIs consist of widgets that contain the state of the GUI screen. Leaving the state of the GUI in widgets makes it harder to get at this state, since that involves manipulating widget APIs, and also encourages putting presentation behavior in the view class. Presentation Model pulls the state and behavior of the view out into a model class that is part of the presentation. The Presentation Model coordinates with the domain layer and provides an interface to the view that minimizes decision making in the view.
The view either stores all its state in the Presentation Model or synchonizes its state with Presentation Model frequently Presentation Model may interact with several domain objects, but Presentation Model is not a GUI friendly facade to a specific domain object. How it Works Figure 2: How objects react to clicking the classical check box. Passive View. A screen and components with all application specific behavior extracted into a controller so that the widgets have their state controlled entirely by controller.
A perennial problem with building rich client systems is the complication of testing them. Most rich client frameworks were not built with automated testing in mind. Controlling these frameworks programaticly is often very difficult. A Passive View handles this by reducing the behavior of the UI components to the absolute minimum by using a controller that not just handles responses to user events, but also does all the updating of the view. This allows testing to be focused on the controller with little risk of problems in the view. How it Works This pattern is yet another variation on model-view-controller and model-view-presenter. Figure 1: Unlike most MVC-style configurations, Passive View results in no dependencies between view and model.
Figure 3: Classes for the assessment example. When to use it Significant Revisions. Using Model View Presenter in WPF - Paul Stovell. I have owned a copy of Sams Teach Yourself WPF in 24 Hours for about a year, and I still find it an interesting book. One thing I like about this book is that doesn't just show off WPF features - it shows how to use the Model-View-Presenter pattern in doing so. The book was written by Rob Eisenberg and Christopher Bennage from BlueSpire, who are also the guys behind the Caliburn WPF framework, so they know a thing or two about the Model-View-Presenter pattern.
Like the Model-View-ViewModel pattern, we can mostly agree upon what the MVP pattern is, but in practice nearly every implementation looks different. I want to highlight some of the differences between my approach to MVP and theirs, and I have attached a sample application that demonstrates these. As in the Teach Yourself WPF in 24 Hours book, my sample application is a contact manager. The application has a shell, and a docking panel like Visual Studio. You can download the code to follow along.
View->Presenter Communication.