There always seems to be a lot of confusion about Model-View-… umm… and-then-something-more architectures.
Everybody seems to get the Model and the View parts. The Model is where your data lives, and the View is where your visualization is. The question is, how should they be linked?
There are a couple of similar but different answers to that last question, and I’ve tried diagramming them as simply as possible here, in the hopes that reducing their essences to the highest level of abstraction may be enlightening.
The differences I’m interested here are the responsibilities of every component, and subsequently, the knows-about relationships. Note that the arrows don’t show data flow. Instead, they show that one component is written with the other one in mind.
Model-View-Controller
The classical edition of this pattern. The Controller’s only job is to mutate the model, and the View only observes the model.
In practice, implementations of this pattern are hardly ever so pure, as the View will create some UI elements that the Controller will need to be aware of, so there will be some coupling between the C and the V.
“Web-Flavored” MVC
A whole bunch of (server-side) web frameworks call themselves MVC. However, invariably, the responsibilities of the Controller in those are more extensive than in classical MVC.
In addition to mutating the Model, they’re typically also responsible for instantiating the Model and the View, and pass the Model to the View.
Model-View-Presenter
In the MVP pattern, coined by Google, the link between View and Model is severed. Instead, the Presenter is responsible for pulling data out of the Model and pushing it to the View.
I don’t have a lot of experience with this pattern, but I guess it makes for nicely testable components. This also gives the opportunity to reuse Views for different Models, but other than for testing, I don’t see that being useful in practice.
Model-View-ViewModel
The MVVM pattern was introduced by Microsoft when releasing WPF (). This pattern actually has two different levels of Models, where the first one is geared more towards data (think *BirthDate) and the second one is geared more towards presentation (think BirthYear, BirthMonth, BirthDay for 3 different dropdowns), to which the view is then bound.
Since Views are typically hard to test, testing is done at the VM level, and since the Views hardly contain any logic their correctness is taken as a given (under the assumption that bugs should be obvious to spot).
(*) which, curiously, lacks the facilities to implement the pattern easily and requires everyone to layer their own abstraction layer on top of the provided classes :).
That’s it
That’s all I have so far. Additions and corrections are welcome!