What are the pros and cons of View-first vs. ViewModel-first in the MVVM pattern

Question

I'm giving a presentation on using MVVM in real world applications and I'm including a section on the religious wars design decisions involved when using MVVM as a pattern in your application. In an MVVM application there are two main ways (that I know of) to instantiate a new View/ViewModel pair:

1. View-First in which you create a view and it creates its own ViewModel and sets it to its DataContext.
2. ViewModel-First in which you create new view models and create new views in response to changes in ViewModel properties, usually with ItemsControls and/or DataTemplates.

In your experience what are the pros and cons of each method? What do they enable and what problems do you run into with each?

Result Summary

---

• View First - Pros
  • Easy to track which ViewModel is used by a View
• View First - Cons
  • Doesn't allow a single View to be easily used with multiple ViewModels
  • Requires extra events to handle communication between Views and ViewModels
• ViewModel First - Pros
  • Allows more complete testing of logic to open new Views and ViewModels
  • Tends to be DRYer as applications get larger
  • View and ViewModel are more independent and can be worked on separately more easily
• ViewModel First - Cons
  • More difficult to set up in Silverlight without DataTemplateSelector and typed DataTemplates.

Answer 1

I use a View-first (sort-of) approach. I define the View in collaboration with my client with a dummy viewmodel with test data. When we are satisfied, I proceed to extract an interface from the 'dummy' and implement the real ViewModel. I've found this approach most appealing for the following reasons:

• It's fast as prototyping is in-expensive time-wise and I often get it right (ish) in the fourth or fifth try.
• ViewModels tend to be easy (easier) to implement when I have an interface to adhere to.

I work in WPF, but I'd think it wouldn't be too different in SL. Also, I never spend time on testing views which may attribute to my choice of approach.

Answer 2

I tend to prefer the View-Model first simply because I feel it follows the DRY rule best. When you start creating larger scale applications I find this makes testing easier as well, thus outweighing the initial bit of headache you need to deal with when setting up the application.

Answer 3

Caveat - I use WPF not Silverlight.

By the VM instantiating the V (which is the way I do it) the view is independent and can be used independently of the VM (e.g. in a designer)

Personally, I am veering toward a MVVMC (model, View, ViewModel, Controller) where I have a controlling class which instantiates ViewModels and Views and 'joins them'. The C also then handles getting data (and caching it, etc.) and any communicating across VM and Vs (e.g if a V is instantiated, routes a command to its VM to perform some action, the VM will probably ask the C to perform the action on its behalf; the C can then raise appropriate events which other VMs can handle

If (whether using a controller or not) I need a VM to talk to another VM, it is harder to do so if the V instantiates a VM - because no I have to expose the VM in the V (or at least make some interface available so the 2nd VM can talk to the 1st).

Answer 4

We've used ViewModel first, but when came in outsourcing, and using of blend became the most important thing, my boss said that View-first is better than Viewmodel-first - I disagreed with him (but one to many is not best ratio of votes ;-) ), because now we have some weirdo connections with events of view in code behind. Now I'm in point of no return and I`ve got stuck in some custom controls - because of the change.