ViewModel instantiation

1,850 views
Skip to first unread message

Paul Stovell

unread,
Jun 8, 2010, 10:12:54 AM6/8/10
to wpf-di...@googlegroups.com
Hey MVVM fans :)

How do you wire your VM to your view? I tried to gather up some of the common patterns I've seen and used:


--
Paul Stovell

Peter O'Hanlon

unread,
Jun 8, 2010, 10:16:03 AM6/8/10
to wpf-di...@googlegroups.com
I use MEFfedMVVM to handle it.
--
Peter O'Hanlon

Paul Stovell

unread,
Jun 8, 2010, 10:23:43 AM6/8/10
to wpf-di...@googlegroups.com
I'm mostly looking at the low-level "how" it happens, rather than the high-level framework that does it. E.g., Magellan uses option 3, but you don't generally see it. 

Going by this post:


I'd say MEFedMVVM uses option 2, with the VM being injected (in this case by MEF) into the view, but still being a dependency. 

Paul
--
Paul Stovell

Bill Kempf

unread,
Jun 8, 2010, 10:37:20 AM6/8/10
to wpf-di...@googlegroups.com
Onyx V1 uses an attached property. This is similar to Option 4, but I
keep the ViewModel and the DataContext as distinct concepts, and using
an attached property allows me to use coercion to simplify the XAML
syntax.

<UserControl onyx:View.ViewModel="{x:Type MyViewModel}">
</UserControl>

I'm probably going to keep this in V2 to be designer friendly, but in
V2 I'm moving to a ViewModel first runtime, so things aren't so clear
cut. I think it would be interesting to consider View First and
ViewModel First in your analysis.

--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

War is peace. Freedom is slavery. Bugs are features.

Sacha Barber

unread,
Jun 8, 2010, 10:40:11 AM6/8/10
to wpf-di...@googlegroups.com
Either attached prop as Bill shows, or MefedMVVM (it rocks)
--
Sacha Barber
sacha....@gmail.com

Glenn Block

unread,
Jun 8, 2010, 10:42:04 AM6/8/10
to wpf-di...@googlegroups.com
In Brook (wwwmgithub.com/glennblock/brook) I use one of two ways in
either case an attached prop does the wire up.

The view model is eithert directly instantaied if you are not using a
container, or it goes through a locatotr.

I have also used the marriage approach having the view and VM wired up
by a 3rd party.

--
Sent from my mobile device

Laurent Bugnion

unread,
Jun 8, 2010, 10:51:32 AM6/8/10
to wpf-di...@googlegroups.com

The approach I use is nicely explained as option 6. However I use StaticResource (I am a Silverlight head, you know ;))

 

Cheers,

Laurent

Glenn Block

unread,
Jun 8, 2010, 10:55:57 AM6/8/10
to wpf-di...@googlegroups.com
Binding to.a resource, direct dependency, attached prop, markup
extensions (wpf) are all techniques I have seen.

On 6/8/10, Paul Stovell <pa...@paulstovell.com> wrote:

--

Josh Smith

unread,
Jun 8, 2010, 11:01:55 AM6/8/10
to wpf-di...@googlegroups.com
I alternate between 1, 3, 4, and 7 depending on the context.

Josh

Brian Noyes

unread,
Jun 8, 2010, 11:26:43 AM6/8/10
to wpf-di...@googlegroups.com

I don’t always do it one way, but more adapt to the situation.

I’d say most often I do #3 in a controller and use DI to instantiate with either MEF or Unity because the VM often has dependencies that I want to inject for testability.

For simpler view models, #7 or #5 work out nicely.

 

I try to avoid coupling the View and ViewModel type if I can and rely on Behaviors and property changes to let them communicate in a loosely coupled way. But sometimes a direct connect is more expedient, in which case I would do #1 because I am OK with my View having a concrete type dependency on my ViewModel since the whole point is to get all the logic code I want to unit test out of the view, so substitutability is not a big concern inside my view type.

 

One you are missing is “ViewModel-first” construction. ViewModel creates the view. This is the approach we took in Prism 1 for all the samples and the reference app. The View got injected into the ViewModel as an interface reference to keep them swappable.

 

Brian

Marlon Grech

unread,
Jun 8, 2010, 12:12:33 PM6/8/10
to wpf-disciples
I use MEFedMVVM :)

it would be quite stupid if I didn't wouldn't it :) hehe

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
Microsoft MVP for Client App

Jeremiah Morrill

unread,
Jun 8, 2010, 1:26:49 PM6/8/10
to wpf-di...@googlegroups.com
Paul,

This is the link I will use when someone asks why there are so many MVVM toolkits!  It should then be apparent with so many not-wrong ways to instantiate the VM/V.

Great stuff.

-Jer

On Tue, Jun 8, 2010 at 7:12 AM, Paul Stovell <pa...@paulstovell.com> wrote:

Marlon Grech

unread,
Jun 8, 2010, 1:30:58 PM6/8/10
to wpf-disciples
very true Jer...

having said that I use MEFedMVVM since I want MEF support... and yes because I built it :P hehehe

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
Microsoft MVP for Client App



Paul Stovell

unread,
Jun 8, 2010, 7:57:40 PM6/8/10
to wpf-di...@googlegroups.com
Hi Brian and Bill,

As far as "view model first" goes, I struggle with this concept, because to me this isn't MVVM. I've written about that here:


I guess my position that in MVVM, the view owns the VM. In MVP, the presenter owns the view. Is this very different to the way you see the world? 

Paul


--
Paul Stovell

Paul Stovell

unread,
Jun 8, 2010, 8:08:28 PM6/8/10
to wpf-di...@googlegroups.com
Sorry, it looks like I got the framework confused. I googled "MEFfedMVVM" and all I got was:


So I went with the first samples I could find there. 

But googling "MEFedMVVM" (one F) gets:


Which is a little different :) I'd say MEFedMVVM is using an approach that combines 6 (a view model locator) with Bill's approach of an attached DP, to locate and set the VM. 

Paul
--
Paul Stovell

Jeremiah Morrill

unread,
Jun 8, 2010, 8:31:30 PM6/8/10
to wpf-di...@googlegroups.com

Paul,

 

I also enjoy view-model first as I usually have more to say to a VM than I do the view.   Usually it’s some interaction that comes from whatever controller-esque (binary aether) mechanism that manages it.

 

I will follow this up with the fact that this is the only way I’ve done it for large projects (small projects might just get a DataContext in the XAML), so I can’t say either is better.  From an ignorant perspective, I am curious about the advantages that view-first gives.

 

-Jer

Karl Shifflett

unread,
Jun 8, 2010, 9:22:33 PM6/8/10
to wpf-di...@googlegroups.com

Paul.

 

I used 1, 2, 4, 7 depending on the situation.

 

For most apps I try and use 4.  I like the design-time support you get for free.

 

Karl

Glenn Block

unread,
Jun 8, 2010, 9:25:23 PM6/8/10
to wpf-di...@googlegroups.com
The main reason for view first is to 'go with the flow' of the
platform and tooling, otherwise it is like rowing a boat upstream.

Glenn

--

Philipp Sumi

unread,
Jun 9, 2010, 1:35:46 AM6/9/10
to wpf-di...@googlegroups.com
View-First is the convenient approach which also allows for simple Blendability - I actually prefer employing it over VM-First. But then, VM-First fits very well with large applications (especially platforms), where you don't want to get tied up with the actual presentation, but rather create your model and VM and delegate the actual rendering (which might be different views depending on the environment) to a service/controller/locator/whateveryounameit. This just feels cleaner to me (and makes me look at View-First as a bit as a code-smell that is just too convenient to abandon). I think VM-first sits pretty well with Magellan, too, IMO :).




On 09.06.2010 01:57, Paul Stovell wrote:
Hi Brian and Bill,

As far as "view model first" goes, I struggle with this concept, because to me this isn't MVVM. I've written about that here:


I guess my position that in MVVM, the view owns the VM. In MVP, the presenter owns the view. Is this very different to the way you see the world?�

Paul




On Wed, Jun 9, 2010 at 1:26 AM, Brian Noyes <brian...@softinsight.com> wrote:

I don�t always do it one way, but more adapt to the situation.

I�d say most often I do #3 in a controller and use DI to instantiate with either MEF or Unity because the VM often has dependencies that I want to inject for testability.

For simpler view models, #7 or #5 work out nicely.

�

I try to avoid coupling the View and ViewModel type if I can and rely on Behaviors and property changes to let them communicate in a loosely coupled way. But sometimes a direct connect is more expedient, in which case I would do #1 because I am OK with my View having a concrete type dependency on my ViewModel since the whole point is to get all the logic code I want to unit test out of the view, so substitutability is not a big concern inside my view type.

�

One you are missing is �ViewModel-first� construction. ViewModel creates the view. This is the approach we took in Prism 1 for all the samples and the reference app. The View got injected into the ViewModel as an interface reference to keep them swappable.

�

Brian

�

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Paul Stovell
Sent: Tuesday, June 08, 2010 9:24 AM

Subject: Re: [WPF Disciples] ViewModel instantiation

�

I'm mostly looking at the low-level "how" it happens, rather than the high-level framework that does it. E.g., Magellan uses option 3, but you don't generally see it.�

�

Going by this post:

�

�

I'd say MEFedMVVM uses option 2, with the VM being injected (in this case by MEF) into the view, but still being a dependency.�

�

Paul

�

On Wed, Jun 9, 2010 at 12:16 AM, Peter O'Hanlon <pete.o...@gmail.com> wrote:

I use MEFfedMVVM to handle it.

�

On 8 June 2010 15:12, Paul Stovell <pa...@paulstovell.com> wrote:

Hey MVVM fans :)

�

How do you wire your VM to your view?�I tried to gather up some of the common patterns I've seen and used:

�


--
Paul Stovell



--
Peter O'Hanlon




--
Paul Stovell




--
Paul Stovell

Marlon Grech

unread,
Jun 9, 2010, 2:53:39 AM6/9/10
to wpf-disciples
paul this is the link http://mefedmvvm.codeplex.com/


Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
Microsoft MVP for Client App



Marlon Grech

unread,
Jun 9, 2010, 2:58:23 AM6/9/10
to wpf-disciples
like Karl I do what is best in the specific situation...

in MEFedMVVM I did quite a bit of effort to support both ViewModel First and View - ViewModel... When I say handling ViewModel first I mean handling it for blendability and to satisy the Imports of the ViewModel once it gets injected via some implicit DataTemplate (I did sometime that I call DataContextAware ViewModels)...

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
Microsoft MVP for Client App



Laurent Bugnion

unread,
Jun 9, 2010, 4:36:06 AM6/9/10
to wpf-di...@googlegroups.com

I think it depends which point of view you work on the application with. To me, in my role as an integrator, I feel that VM-first is unnatural. My playground is the View, the VM is merely a servant of the view, and as such the view comes first. It’s not just a matter of tooling (though I also think that VM-first is rowing against the flow), but also a matter of what I concentrate about, I guess.

 

I guess that in developer-driven projects, VM-first comes naturally, and I am OK with that. In firms like ours where the integrator is the owner of the view, though, viewmodel-first comes more as a hindrance. Doesn’t mean we can’t do it, but it’s more painful, and I am a bit weird with pain: I try to avoid it ;)

 

Cheers,

Laurent

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Philipp Sumi
Sent: Wednesday, June 09, 2010 7:36 AM
To: wpf-di...@googlegroups.com
Subject: Re: [WPF Disciples] ViewModel instantiation

 

View-First is the convenient approach which also allows for simple Blendability - I actually prefer employing it over VM-First. But then, VM-First fits very well with large applications (especially platforms), where you don't want to get tied up with the actual presentation, but rather create your model and VM and delegate the actual rendering (which might be different views depending on the environment) to a service/controller/locator/whateveryounameit. This just feels cleaner to me (and makes me look at View-First as a bit as a code-smell that is just too convenient to abandon). I think VM-first sits pretty well with Magellan, too, IMO :).





On 09.06.2010 01:57, Paul Stovell wrote:

Hi Brian and Bill,

 

As far as "view model first" goes, I struggle with this concept, because to me this isn't MVVM. I've written about that here:

 

 

I guess my position that in MVVM, the view owns the VM. In MVP, the presenter owns the view. Is this very different to the way you see the world? 

 

Paul

 

 

 

On Wed, Jun 9, 2010 at 1:26 AM, Brian Noyes <brian...@softinsight.com> wrote:

I don’t always do it one way, but more adapt to the situation.

I’d say most often I do #3 in a controller and use DI to instantiate with either MEF or Unity because the VM often has dependencies that I want to inject for testability.

For simpler view models, #7 or #5 work out nicely.

 

I try to avoid coupling the View and ViewModel type if I can and rely on Behaviors and property changes to let them communicate in a loosely coupled way. But sometimes a direct connect is more expedient, in which case I would do #1 because I am OK with my View having a concrete type dependency on my ViewModel since the whole point is to get all the logic code I want to unit test out of the view, so substitutability is not a big concern inside my view type.

 

One you are missing is “ViewModel-first” construction. ViewModel creates the view. This is the approach we took in Prism 1 for all the samples and the reference app. The View got injected into the ViewModel as an interface reference to keep them swappable.

 

Brian

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Paul Stovell
Sent: Tuesday, June 08, 2010 9:24 AM

Subject: Re: [WPF Disciples] ViewModel instantiation

 

I'm mostly looking at the low-level "how" it happens, rather than the high-level framework that does it. E.g., Magellan uses option 3, but you don't generally see it. 

I'd say MEFedMVVM uses option 2, with the VM being injected (in this case by MEF) into the view, but still being a dependency. 

 

Paul

 

On Wed, Jun 9, 2010 at 12:16 AM, Peter O'Hanlon <pete.o...@gmail.com> wrote:

I use MEFfedMVVM to handle it.

 

On 8 June 2010 15:12, Paul Stovell <pa...@paulstovell.com> wrote:

Hey MVVM fans :)

 

How do you wire your VM to your view? I tried to gather up some of the common patterns I've seen and used:

 


--
Paul Stovell



--
Peter O'Hanlon




--
Paul Stovell




--
Paul Stovell

 

Bill Kempf

unread,
Jun 9, 2010, 8:51:16 AM6/9/10
to wpf-di...@googlegroups.com
Yes. I don't think either owns the other. I think the concepts are
more decoupled than that. I also believe that both can depend on the
other (that's different than owns) in different circumstances. More
importantly, though, I think that View First leads to overly
complicated coding scenarios. Common dialogs, message boxes, custom
dialogs, navigation... all of these are things that are much more
difficult to deal with in a View First design.

Regardless, I'm not suggesting you pick ViewModel First over View
First, or the other way around. I'm only suggesting that this decision
is at least as important as how you wire the parts together, and it
greatly impacts the how. I'd not cover one topic without covering the
other.

--

Bill Kempf

unread,
Jun 9, 2010, 8:51:58 AM6/9/10
to wpf-di...@googlegroups.com
Yes. I don't think either owns the other. I think the concepts are
more decoupled than that. I also believe that both can depend on the
other (that's different than owns) in different circumstances. More
importantly, though, I think that View First leads to overly
complicated coding scenarios. Common dialogs, message boxes, custom
dialogs, navigation... all of these are things that are much more
difficult to deal with in a View First design.

Regardless, I'm not suggesting you pick ViewModel First over View
First, or the other way around. I'm only suggesting that this decision
is at least as important as how you wire the parts together, and it
greatly impacts the how. I'd not cover one topic without covering the
other.

On Tue, Jun 8, 2010 at 7:57 PM, Paul Stovell <pa...@paulstovell.com> wrote:

--

Peter O'Hanlon

unread,
Jun 9, 2010, 8:59:54 AM6/9/10
to wpf-di...@googlegroups.com
Bills comments. So important, they come through twice.
--
Peter O'Hanlon

Brian Noyes

unread,
Jun 9, 2010, 12:35:50 PM6/9/10
to wpf-di...@googlegroups.com
Exactly what I've found too, and why I've migrated away from VM-first
since we did that in Prism. I don't remember how/why we convinced
ourselves that was the way to go on the Prism team. But it was at least
partially because of the other comments made in favor of VM-first:
specifically that when you are totally code-focused, and have a framework
like Prism that favors putting everything together behind the scenes and
treating the View as just "implementation details" of the model instead of
the other way around, VM feels more natural. But I've definitely struggled
with using that and not fighting with the tools.

-----------------------------------------
Brian Noyes
Chief Architect, IDesign Inc
Microsoft Regional Director / MVP
http://www.idesign.net
+1 703-447-3712
-----------------------------------------

Bill Kempf

unread,
Jun 9, 2010, 12:48:06 PM6/9/10
to wpf-di...@googlegroups.com
I've been going the other direction. Onyx was View First, and included
things like the ICommonDialogProvider service to work around the
issues with being View First. Since then, I've been concluding that
View First is ONLY useful within the confines of the designer, and a
"hybrid" approach that allows the designer to work View First, but the
application to work ViewModel First, is really the way to go. The
comments about rowing upstream are spot on, but since there's two
boats going in opposite directions one will always be rowing up stream
if you can only pick one.

--

Reply all
Reply to author
Forward
0 new messages