What are the differences between Presenter, Presentation Model, ViewModel and Controller?

Besides the already mentioned great reads (Fowler & Miller) and to reply to your point on differences among controller/ presenter/ ... from the developer's point of view:

Controller in MVC:

  • Controller is the actual component that gets called as a result of user interaction. (Developer does not have to write code to delegate calls to the Controller.)

  • Controller gets current values somehow from the View/ context/ bag/ whatever, but you would not really say that it interacts with the View.

  • Controller decides in the end which View to show back to the user. In that, Controller shows an explicit notion of application navigation workflow too.

Presenter in MVP:

  • Presenter has methods called by the View, which is the actual component receiving control upon user interaction. (Developer has to write some code in the View in order to call the Presenter.)

  • Presenter gets current values somehow from the View or receive them from the View upon call. Presenter calls methods on the View in order to set its state (populate it says Josh Smith). A View method called by the Presenter might have several small settings performed in its body.

  • Presenter does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.

PresentationModel in PM:

  • PresentationModel has methods called by the View, which is the actual component receiving control upon user interaction. (Developer has to write some code in the View in order to call the PresentationModel.)

  • PresentationModel has a much more chatty communication with View compared to a Presenter. It also contains more logic in order to figure out the value of all the settings to apply in the View, and to actually set those in the View. (Those View methods in turns have almost no logic.)

  • PresentationModel does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.

ViewModel in MVVM:

  • ViewModel has methods called (& properties set) by the View, which is the actual component receiving control upon user interaction. (Developer has to write some (declarative) code in the View in order to call the ViewModel.)

  • ViewModel has not an explicitly chatty communication with View compared to PresentationModel (i.e. it does not call View a lot, the framework does it). But it has a lot of properties that map 1 to 1 with View settings. It still contains the same logic to figure out the value of all those settings.

  • ViewModel does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.

  • Copying somehow what Josh Smith says (http://msdn.microsoft.com/en-us/magazine/dd419663.aspx): MVVM pattern is a special case of PM that takes advantage of a framework (like WPF/SL) in order to write less code.


Martin Fowler has a page on UI design patterns, in which he defines and then talks about MVC, MVP and other patterns.

http://martinfowler.com/eaaDev/uiArchs.html

A Controller is active in controlling the UI. For example it would handle any events triggered by the UI and deal with them appropriately.

A Presenter on the other hand is more passive, and simply displays data through the UI, which handles it's own events etc, or delegates them through the presenter to a service or command.

A ViewModel is a specific example of a Presenter, designed for use with WPF/Silverlight binding.

A Presentation Model is a model that can be presented directly by the view, so for example if your models implement INotifyPropertyChanged for data binding, they would be Presentation Models.


The difference between them is essentially in how much code is in the view. The choice between them is in fact a choice of technology for application such as WFP, WinForms, ASP MVC(2). The basic idea of separating logic from presentation is the same.

Here is very good article about all three.

EDIT:

One more article - comparison.