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

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 an开发者_如何学Pythond 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.

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.

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.

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.

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.

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.