There are 3 main variants of the same basic pattern:
- Model-View-Controller: The granddaddy of them all. Originally defined with Smalltalk
- Model-View-Presenter: Variant created primarily to deal with the limitations of Windows Forms architecture. Suits technologies where the UI cannot directly bind to the model
To understand the variants, it helps to understand the original architectural pattern, and how separated concerns. The truth is that all three variants agree on both the Model and the View, with differences in how you model control.
The Smalltalk concept of a Model was something called a Domain Model. The key difference is that the Domain Model also has the methods that each object needs to do within the client's domain. Essentially it is the application without any UI.
The Smalltalk concept of a View was something that could bind directly to your model. Buttons would bind to a method, text boxes would bind to the setters/getters, etc. It would also bind to something called a Controller.
The Smalltalk concept of a Controller is functionality that is for the application in general. For example your menu items that have "Save" and "Load" options, etc. are bound to a Controller that in turn does things with the Model. The "Save" controller is an object that would take the domain root and serialize it to disk or something like that.
Web based MVC applications have something called a Controller that maps URLs to methods that interact with a Model and bind it to a view.
WinForms (Windows Forms Applications) and things like it don't have direct binding. There are several functions on a UI where changing the value on a combo box affects the state in other places.
Typically for this and later variants the model is more of a "Data" model. In other words it's just the properties that make up the data for your business objects.
The Presenter is the combination of an interface and an implementation. The interface is something the model knows about, so changes that originate from the model can update the view. The implementation knows about the view and works intimately with it. It handles the UI related changes that have to happen, and then uses a callback to let the model update itself.
There is always one presenter implementation with every view. The interface can be reused, but typically it isn't.
It's a lot of work, so most people don't use MVP. It is about the only way to make applications based on WinForms testable though.
A View Model defines all the view specific properties and interactions, and exposes the model through a bindable property called "Model". That allows the model to be ignorant of UI concerns, but still allows the view to be as interactive as we want. The View can bind directly to the model, or to the view specific properties.
In practice there is usually one View Model per View, though in theory it's not necessary.
- MVC started it all.
- Models represent your business data and logic in all three variants
- Views represent what the user interacts with in all three variants
- The primary difference is how the view interacts with the model
- Controllers respond to the view and act on the model
- Presenters act as a bridge between the model and the view when you can't automatically interact with it (i.e. binding).
- View Models add a layer of view specific models that the view can bind to and interact with the model that way
Which one you actually end up using is really dictated by the technology you are using. All three enable you to test the application thoroughly without invoking a UI.