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

Question

I have a pretty good idea how each of these patterns work and know about some of the minor differences between them, but are they really all that different from each other?

It seems to me that the Presenter, Presentation Model, ViewModel and Controller are essentially the same concept.

Why couldn't I classify all of these concepts as controllers? I feel like it might simplify the entire idea a great deal.

Can anyone give a clear description of their differences?

I want to clarify that I do understand how the patterns work, and have implemented most of them in one technology or another. What I am really looking for is someone's experience with one of these patterns, and why they would not consider their ViewModel a Controller for instance.

I'll give some reputation points for this, but I'm looking for a really good answer.

Kala

This answer may also suit one interested in a very simple comparison of them: https://mcmap.net/q/116444/-what-is-difference-between-mvc-mvp-amp-mvvm-design-pattern-in-terms-of-coding-c – Centerboard

Answer 1

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 receives 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.

Kowalski

Could you mention something about which of these design patterns are used in different frameworks (ASP.NET MVC, WPF, SL)? – Lohengrin

I absolutely don't presume to know all frameworks around there. You mentioned .NET ones: ASP.NET MVC, with Views and Controllers is quite adherent to MVC (same should be for Ruby on Rails); WPF/SL are quite adherent to MVVM with XAML UI components and C# code behind. To me, Caliburn.Micro gets even closer to MVVM in its ViewModel-first approach. Even if dubbed as MV*, AngularJS is also quite a MVVM example to me, provided view does not hold too much code. – Kowalski

Taking the chance to insert link to Jeremy Miller articles, Build Your Own CAB Series, as the answer mentioning them is hidden to some users – Kowalski

Answer 2

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.

Tympan

Answer 3

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.

Rayburn

I've seen a lot of articles on this topic, but not that one. It looks very complete, thanks. However, I want to mention that the only pattern that is technology dependent is MVVM, and even this one can be implemented identically in Flex for instance. – Kala

Answer 4

In my opinion, there are no real conceptual differences between MVP, MVVC, MVC and Presentation Model. There are some detailed differences, but in the end, it can all continue to be thought of as a Model View Controller setup. The extra naming just serves to create confusion, and I think it would be better to adopt terminology that allows for a certain amount of latitude in describing a controller.

Kala

In your opinion? I think the OP asked for an answer, not for opinions. Besides, there are clearly differences. In my opinion, this answer was bad. – Anfractuous

@Anfractuous Ha aha h... I was the one who ask the question smart guy. – Kala

This is priceless. – Meadors

Nevertheless I don't think this is the place to express your opinion, that's not an answer. If anywhere it's as part of the question you would put it (not that it's the question, but it provides some kind of background/context to it at least). – Overact

Answer 5

One important distinction between MVP and MVVM is that VM can be used with many views, MVP is usually 1-1 between Presenter and View with a contract interface that enforces its methods. Android has done much to incorporate MVVM with the ViewModel component that is built on top of a retained Fragment. It is the pattern of choice for Architecture and well suited for any app.

Chavaree

Answer 6

At least in .Net, MVP is used as a design pattern. This usually is used with Windows Forms applications, or classic ASP.Net . With MVC, and MVVC, these are usually used with ASP MVC, which uses a fairly different architecture than normal ASP.Net.

Departmentalize