ViewModel / PresentationModel

Jan 19, 2009 at 12:32 AM
Are these 2 terms 100 % interchangeable, or do they mean different things.
Jan 19, 2009 at 2:46 AM
Edited Jan 19, 2009 at 2:47 AM
Within the context of WPF they are the same thing. - Google search on MVVM (Model/View/ViewModel)  - Martin Fowler

As for which is more correct - you really have to consider the source (which is very hard to find sometimes).  For example,  a few years back almost every site I went to said that in the MVP (Model-View-Presenter) pattern that the View does *not* communicate with the Model.   I trust they still mislead you today but I wouldn't know because there are only two sources I frequent now for architecture research - Microsoft and Martin Fowler (in that order).   In the absence of guidance by Microsoft Fowler gets it.   Why?

When the Model-View-Presenter (MVP) pattern evolved from the Model-View-Controller (MVC) pattern the most significant changes were the "levels of abstraction" (don't take my word for it - I recommend you read it from one of our MVP founding fathers - Mike Potel).  See following link:

So where did the mis-understanding come from?  My suspicion is from Martin Fowler in 2006 when he "split" MVP into two - the Supervising Controller and Passive View.  In "Passive View" it is correct that the Presenter is responsible for updating the view (manually) and the View does not communicate with the model.   If you read Fowlers comments on "Supervising Controller" you'll find he notes that if you using DataBinding (View indirectly monitors the Model) then the pattern is "Supervising Controller".  

So if Martin Fowler could have such a great impact on the community then my vote is to call it PresentationModel; after all MVVM really doesn't make a lot of sense when it is more View-ViewModel-Model or in the case of my application;
      View-ViewModel - Presenter - Model. 
I am following a CompositeWPF pattern from the TopDown composition sample where the Presenter communicates with the Model to update the PresentationModel (indirectly updating the view via DataBinding).

In my humble opinion there is no place for Passive MVP in the ASP.NET, WinForm and WPF world - we have smart controls and smart infrastructures to do the hard work for us (via DataBinding).


Soooo, just when I thought I had a clear understanding on the difference between MVP and MVC, Microsoft came out with ASP.NET MVC - Phil Haack explains the difference between MVP and MVC in the following:

Why MVC?  Was clear as mudd when I got done reading his blog...  I'm one of the last comments on it - perhaps one day someone will be able to clear it up????  

Jan 19, 2009 at 10:08 AM
Edited Jan 19, 2009 at 10:29 AM

I would go with Bill and say that supervising type of view is better choice for WPF/SL/ASP.NET which are heavily supporting data biding approach. But there is a case at least one I have encounter so far, where Supervising type of MVP is not most feasible as declarative or indirect data binding is not allowed by control, and such unusual case is when your view contains PasswordBox control.

PasswordBox control does not allow you to data binding to control content changes. You can go around of this by subscribing password change event and then apply the changes into your model but the code looks ugly as you compromise the concept by one (exception) control. Also you should be careful here as such information as password is sensitive and if you move it out from PasswordBox control, the content (password) will be hanging as naked string in your model and in client site SL CLR till the GC cleans it up.

So, I think some cases passive type of MVP is better choice, like above or when you need to encrypt the control content (Bank Account, Password, SSN) and limit your controls data biding by security reasons.

Just my humble observation and comment to this topic...


Jan 19, 2009 at 12:25 PM

I created a diagram presenting the difference of typical CreateUser view (which I mention above) where you could use declarative data binding as supervising type partially,and for security sensitive info you could mix the use of typical Passive type of MVP. The diagram here is a bit out of standard UML Sequence diagram but I hope this illustrate the difference in more visually.

Anyhow, see the diagram link (there is no way to attach it to this discussion here so I made it as link)

Hope above clears the differences...

Jan 19, 2009 at 12:35 PM
Edited Jan 19, 2009 at 12:37 PM

Very, very nice Alexander – I’m keeping this one for my next Story/Use case (one less thing to document!).   I have to create an authentication model that will support both ADS and ASP.NET security for Silverlight, ASP.NET and our CompositeWPF apps; if the user doesn’t authenticate via ADS then I have to provide a login form.


Jan 19, 2009 at 8:17 PM
This is awesome Alex. Thanks a lot!!!
Jan 22, 2009 at 2:41 AM
Edited Jan 22, 2009 at 2:55 AM
Thanks for all the replies, and thanks Alex for the diagram (this is going on the wall for sure).
All of this definitely helped clear up some stuff for me, but perhaps brought up a few questions as well.
In this type of scenario, how would you envision the model being implemented.
I imagine it would it be help as a property in the presenter, and then set as the data context of the view, but I wanted to make seeing things from the same perspective.
Jan 22, 2009 at 10:43 AM

There are couples of different ways to do this and I would recommend you to look into the quick starts and get dirty in code.

You are close by now as you asking right questions, so to help you on star, take a look of following quick starts and debug them.

PrismV2 code drop 9 and particularly Visual Composition Quick Starts. See EmployeesModule, IEmployeesDetailsView which has a Model (Property) and defines EmployeesDetailsPresentationModel contract.

There is a good Unity Silverlight Quick start sample that does not use Composite but just Silverlight Unity. You can find this sample from Unity Contrib. site source code  

This is tricky and requires some time, but once it’s clear it’s so clear. If this is still not clear and you getting lost,  please send me an email from my CodePlex profile and I can schedule a 5-10 minutes application sharing chat with you by using MSN. If we go for this then I reserve rights to record and publish this chat in Codeplex in learning purpose for others.

Jan 23, 2009 at 12:41 PM

Hi Kona,


Here is a good video that explains the Model-View-ViewModel pattern, that I personally liked. You can download the video and the source code of the demo application built in it from the following blog posts:

·         Jason Dolinger on Model-View-ViewModel

·         Source code for Jason Dolinger’s Model-View-ViewModel presentation


Have you seen this video before? What are your thoughts about it?


Mariano Converti

Jan 27, 2009 at 1:21 AM
Edited Jan 27, 2009 at 2:57 AM
Thanks again for all the great responses and resources.
Excellent video.

One of the things that Jason kept mentioning that now makes things clearer is:

"You know you are doing things right when you don't need x:Name on your elements in your view"

This is because those values are already available on the view model from the databinding.

Previously, I was thinking that a click handler would have to pass data to the view model, but now I realize that the handler in the code behind should really just be a 1 liner that calls a method on the view model.