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

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.

Given the Data Templating feature in WPF, I feel ViewModel-First is the way WPF was intended to be used.

I'll clarify that statement: Data Templating allows you to never instantiate views from your ViewModel. If done correctly, your Views and ViewModels could be kept in seperate projects that DO NOT reference each other. Furthermore, the ViewModel project should not even reference any PresentationFramework assemblies, making your ViewModels consumable by any conceivable user.

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.

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

I prefer to use view model first approach. For many reasons:

• Vms are your application containing most of logic apart from glue code in form of behaviors or triggers.
• If you creates views then you are responsible for its life and cleanup code. You have to deal with threading and other issues which are difficult to test. On the other hand of you create vms and leave the view creation logic with WPF via data template.. you don't have to worry about threading issue. And there will be better separation of concerns.
• With vm first approach zero code behind.
• With a project level isolation for view and vms you can restrict developers using view specific things like dispatcher in the view model leaving more cleaner and testable code base. I.e view project sprojec to vm. And vm project should not refer to any presentation lib.
• If there is clear boundary between view and vm. Both can evolve and will be less fragile.

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.

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.