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