tags:

views:

443

answers:

2

I've been using MVVM for the past two years and it has certainly evolved for the better since that time. As I read though the hundreds of MVVM articles and stackoverflow questions, I've noticed that there appears to be more and more articles that describe the view/viewmodel relationship and creation as ViewModel first or View first. These articles usually use IoC or DI. I'd include some links but as a new SO user I'm only limited to 1.

My favorite technique has been the use of datatemplates to create the views, and structuring the application off the the viewmodels rather than the views. I rarely see articles anymore that use this pattern.

<DataTemplate DataType="{x:Type ViewModels:DummyViewModel}">
  <Views:DummyUserControl DataContext="{Binding}"/>
</DataTemplate>

Testability and decoupling seem to be the main focus of these 'non-datatemplate' V-VM creation/relationship designs and articles, and often they have to do with MEF or PRISM. Ultimately I would like to know the following:

  1. Is the DataTemplate view creation technique still used or recommended?
  2. What are the pros/cons of the view first design?
  3. What are the pros/cons of the viewmodel first design (with the view injected)

I realize these are loose questions which deserve loose answers.

Any good links to articles covering these topics is appreciated, provided they are not MEF/PRISM related. The more the better. (Google turns up quite a few)

+1  A: 

1.Is the DataTemplate view creation technique still used or recommended?

This is my preferred method of operating in MVVM. I like this approach very much, for reasons I'll specify below. I use this in all of my development.

2.What are the pros/cons of the view first design?

The main pro here I've found is that it's a bit easier in the design time experience. The designer "knows" the data context in advance, and tends to be able to do an easier job of working.

The main con here, from my perspective, is that you're adding a tighter coupling between the View and the ViewModel. It's also more difficult to choose a specific model for passing around.

3.What are the pros/cons of the viewmodel first design (with the view injected)

I personally like this approach. This way, the "logical" side of your application is completely contained within your ViewModel layer. By using ContentPresenters, you can have the ViewModel easily generate other ViewModels, defining the "flow" of your application. The Views can be changed by a designer very easily.

The con here, though, is a slight decrease in design time usability, though- since the views don't really know anything about the VM at design time, you lose some designability.

Reed Copsey
Well that nails my own experiences and opinions 100%. With so much written lately about using containers to generate the views and viewmodels, I was getting worried I was 'missing the boat.'Do you inject your view into your viewmodel using an interface? Personally, I don't want my viewmodels having any reference at all to the view.
I didn't mention MEF - but I actually use it, too. It's very useful for handling edge cases in the above (ie: services), as well as actually doing the data templates. You can use MEF to setup your DataTemplates from within your View, without having to "pollute" your app.xaml, for example...
Reed Copsey
Your blog (http://reedcopsey.com/) is awesome, btw
Thanks! I appreciate the feedback.
Reed Copsey
Why is tight coupling between View and ViewModel a con?
Robert Rossney
It reduces the flexibility in the design. Keeping a loose coupling in all parts of your development, when possible, makes it much easier to change any single part without breaking anything. The tighter the coupling in your design, the less flexible your overall design becomes.
Reed Copsey
A: 

We experienced that the DataTemplate approach has some limitations. By example the template is instantiated as shared (singleton) instance. In some scenarios this has undesirable side effects. That’s the reason we use the ViewModel first design (with the view injected).

The approach we use is described on the WPF Application Framework (WAF) project page:

http://waf.codeplex.com/wikipage?title=Model-View-ViewModel%20Pattern&amp;ProjectName=waf

jbe