Controllers listen for, and publish, events. Controllers provide the logic that controls what data is seen and where. Controllers provide the command code to the ViewModel so that the ViewModel is actually reusable.
Models hold the actual data (various context, store or other methods)
ViewModels hold a certain shape of data and commands, they do not know where the data, or code, comes from or how it is displayed.
Views display a certain shape of data. They have no idea where the data comes from.
*Note: in practice Controllers remove most of the logic, from the ViewModel, that requires unit testing. The VM then becomes a dumb container that requires little, if any, testing. This is a good thing as the VM is just a bridge, between the designer and the coder, so should be kept simple.
@Justin: I see my wording of that sentence is a little ambiguous. I actually mean unit-testing for all components is more easily supported, not specifically just improving testing of ViewModels (which as you point out don't actually do that much in MVCVM... which is what you want). The real benefit of controllers is that you are actually removing most of the requirements for testing from the ViewModel (where people keeps shoving controller logic) and putting it where it can be tested (mainly Controllers and Models). The reuse comment is specific to the VMs in that sentence. I have edited it.
@Tomasz Zielinski: True, but "where they are used" was not the question (or the point of my answer). My point is that controllers are still useful in MVVM.
An additional benefit of using an MVCVM model is that only the controller objects need to exist in memory for the life of the application and the controllers contain mainly code and little state data (i.e. tiny memory overhead). This makes for much less memory-intensive apps than solutions where view-models have to be retained and it is ideal for certain types of mobile development (e.g. Windows Mobile using Silverlight/Prism/MEF). This does of course depend on the type of application as you may still need to retain the occasional cached VMs for responsiveness.
Even in MVVM, controllers will typically contain all processing logic and decide what data to display in which views using which view models.
For ASP.Net, MVVM is used to two-way bind data within views. This is usually a client-side implementation (e.g. using Knockout.js). MVC on the other hand is a way of separating concerns on the server-side.
For Silverlight and WPF, the MVVM pattern is more encompassing and can appear to act as a replacement for MVC (or other patterns of organising software into separate responsibilities). One assumption, that frequently came out of this pattern, was that the ViewModel simply replaced the controller in MVC (as if you could just substitute VM for C in the acronym and all would be forgiven)...
From what we have seen so far the main benefit of the ViewModel pattern to remove code from XAML code-behind to make XAML editing a more independent task. We still create controllers, as and when needed, to control (no pun intended) the overall logic of our applications.
I agree. My comment was caused by sudden enlightement and not because I disagreed with you.
I have started a blog on this topic which I will add to as and when I can. There are issues with combining MVCVM with the common navigation systems, as most navigation systems just use Views and VMs, but I will go into that in later articles.
Isn't it that MVC is used to architect the whole (web) application, while MVVM is used inside View component of MVC ? So the whole paradigm would be M(VVM)C
The problem is: that to be independently testable*, and especially reusable when needed, a view-model has no idea what view is displaying it, but more importantly no idea where its data is coming from.
The two patterns crop up, in different ways, in both ASP.Net and Silverlight/WPF development.
We also noted that the Sculpture code-gen framework implements MVVM and a pattern similar to Prism AND it also makes extensive use of controllers to separate all use-case logic.