Jul 13, 2010 at 11:40 PM
Edited Jul 13, 2010 at 11:47 PM
Good question, based on the
Separated Patterns in the
Prism documentation this quickstart uses MVP with “Presenter First Composition” since the presenter is created first and then hooked up to a suitable view and a model.
Supervising Pattern as well as
Presentation Model are variants of the MVP. This quickstart uses
Supervising Pattern, since views are updated by presenters, and views interact with presentation models/models. Also this quickstart is mentioned in the
Supervising Pattern under the section
Example as sample.
Regarding to whether EmployeesPresentationModel and EmployeesListPresentationModel should exist, for an "orthodox way" the answer is yes, tough they are not strictly needed. The presentation models are needed when you want to bind a view to a non-existent
property in the model. In this cases, a presentation model exposes those properties in a bind-able way without changing the model itself. For example, the EmployeesDetailsPresentationModel wrap the model to expose the AddressMapURL, which does
not exist on the Employee model. For more information about data binding:
It is possible to move the EmployeeDetailsPresentationModel logic to the presenter. But this would imply that the presenter has to set the AddressMapURL to the view (through the view interface). In addition, if you need the view to be
updated every time the AddressMapURL changes, the presenter would need to observe the model. On the other hand, with the presentation model approach you are taken
advantage of bindings to avoid this extra work.
Presentation Model pattern unifies the presentation logic and bind-able content in only one class (usually called ViewModel). This pattern is also known as Model-View-ViewModel, which
is used in the new
Back to Supervising Pattern, ideally all the bind-able content like properties (e.g. AddressMapURL) live in a presentation model or in a model. While all the complex interaction between
view –> model and model –> view in a presenter. The following examples are some of common interactions considered complex:
- Change the color of a control.
- Hide/Show controls dynamically.
- Listen a click button or menu item.
However, Prism provides guidance, so you could choice either to follow the patterns as they are proposed or make your own implementation.
I hope you can find it useful.