MVPVM - Model View Presenter View Model

"Those who cannot remember the past are condemned to repeat it."
   - George Santayana

See new blog on topic for additional information MVPVM, Dec 2010.  If you don't know the difference between MVC and MVP then you'll want to read this MVC, Dec 2010

If you have to put code in your WPF code-behind, for any reason, then you've run into a limitation of MVVM alone;  a limitation that will prevent reuse, prevent proper unit testing and cause code bloat.   This limitation was identified in the evolution of architectural patterns requiring the need to evolve to the Model View Presenter pattern (MVP).  

History would tell us that the evolution of architecture (because of smart controls, newer technologies and limitations of older architectures) evolved as follows: 

MVC (Model View Controller)
 -> PresentationModel aka ApplicationModel aka MVVM
     ->  MVP  (Model View Presenter)
           -> MVP Split into Supervising Controller and Passive View

Understanding that the PresentationModel and MVVM are synonymous, the question to ask yourself when deciding to use MVVM alone is "what were the limitations that inspired the birth of MVP via the Potel and Twisting the Triad papers?".   For our environment the answer  was simple - we need a presenter. 

----------------------------------------------------------------------------------------------------

Although the following equation is true there are subtle differences that warranted a new name for the reasons John Gossman notes.  We'll reference authoritative sources on the differences.

Presentation Model = Application Model = MVVM  

In John Gossman (founding father of MVVM) "PresentationModel and WPF" John writes:

  • "On naming, my opinion at this point is the the Model-View-ViewModel pattern is a WPF-specific version of the PresentationModel pattern.  PresentationModel is a lot easier to say and to write, and is more widely known...but for now I'm sticking to M-V-VM terminology in my own thinking in order to capture the WPF-ness and to avoid any interpretation conflicts."

In Martin Fowlers "Presentation Model", 2004 article he defines the Presentation Model as follows:

  • "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. Instead it is easier to consider Presentation Model as an abstract of the view that is not dependent on a specific GUI framework. While several views can utilize the same Presentation Model, each view should require only one Presentation Model."

In Martin Fowlers "Gui Architectures", 2006 article he states the following about Application and Presentation Models:

  • "The main difference between using an application model and classic MVC is that we now have an intermediate class between the domain model class (Reader) and the widget - this is the application model class. The widgets don't access the domain objects directly - their model is the application model." - para below figure 9.
  • "Application models allow us to separate behavior and state that's particular to the UI from real domain logic." - 2nd para above Figure 11
  • "Directly updating the widgets like this is not part of Presentation Model, which is why the visual works application model isn't truly a Presentation Model. This need to manipulate the widgets directly was seen by many as a bit of dirty work-around and helped develop the Model-View-Presenter approach".  - para below figure 11.

----------------------------------------------------------------------------------------------------

So why a new name - MVPVM?

"to avoid any interpretation conflicts" - John Gossman

Why is MVPVM necessary?

Short version - for reusability and to have a clear separation of concerns.  

Longer version - For all the reasons we evolved to both MVP and MVVM; they are still valid and the same problems are still being solved.  The only difference is that neither can solve the problem alone "easily".

What is the problem being solved?

We are using MEF/PRISM/Unity for the dependency injection of reusable components.  We may have a need to update the widget (view) directly depending on the complexity of the requirement (will one line of code remove the need for complex bindings); we want an extensible framework that will provide us the option.  Let's use the following Visual Studio 2010 use case diagram as the basis of this discussion.

 

Reusable component:  Person View; it is a UserControl that is resolved (instantiated) by the applicable presenter (its relation to the presenters are not shown in diagram to reduce complexity) 

Business rules:  Only the Admin Staff can view the Social Security Number field of the Person View. 

Assumption: There will be numerous business rules that will affect the behavior of the view.

THE PROBLEM / SOLUTION SCENARIO

We're starting our sprint and I'm handed the "Add Patient" requirement.  It has a business rule that states only Admin Staff can have access to the SSN field.  The user wants a list of patients sorted by last name so that they can verify that the patient in question is not already in the system.  This list should be tied to a lookup field that will locate records in the list as the user types the letters of the name.

I would start by grabbing the available reusable views, user controls created by designer(s), to compose my main screen with.  In our example we'll focus solely on the "Person View".   From the use case diagram I can see that this view has a "Person View model" that it binds to with a provision for the SSN Visibility rule; the Person View will reflect the state of this behavior {collapsed, hidden, visible} effectively showing/hiding the SSN field based on its settings.

Problem:  I can see by the high level use case that I won't be the only presenter that implements this view (and view model).  I can't pollute the ViewModel with any business logic or data access logic.

Solution:  Have my presenter retrieve Patient Records (where personType=Patient) and use it to populate a ListBox.  The presenter will subscribe to the selected index change event of this ListBox via the EventAggregator and when the presenter is notified that a user has changed a patient it will update the PersonViewModel fields as applicable.   The presenter will set the SSNVisibility property to "Visible" and our job with the PersonView and it's view model is done.  

Could a switch statement for visibility be placed on the PatientViewModel?  Yes and it will also have to know who the actor (parent) is that is consuming it.   Can it retrieve the user record?  Yes and it would require knowledge of the patient's primary key.   Will every process require data access to get the record?   Probably not - the information could reside in another control.  

In our environment we want to remain loosely coupled to minimize, if not remove, any impact on other users of a view (and its view model).

 


Tags: ,
Categories: MVPVM


Actions: E-mail | Permalink |  Grammar/Typo/Better way? Please let me know