ViewModel instantiation
Paul Stovell
--
Paul Stovell
Peter O'Hanlon
Peter O'Hanlon
Paul Stovell
Paul Stovell
Bill Kempf
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
Glenn Block
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
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
extensions (wpf) are all techniques I have seen.
On 6/8/10, Paul Stovell <pa...@paulstovell.com> wrote:
--
Josh Smith
Brian Noyes
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
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
Marlon Grech
having said that I use MEFedMVVM since I want MEF support... and yes because I built it :P hehehe
Paul Stovell
Paul Stovell
Paul Stovell
Paul Stovell
Jeremiah Morrill
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
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
platform and tooling, otherwise it is like rowing a boat upstream.
Glenn
--
Philipp Sumi
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
Subject: Re: [WPF Disciples] ViewModel instantiation
Sent: Tuesday, June 08, 2010 9:24 AM
�
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
Marlon Grech
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)...
Laurent Bugnion
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
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
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
Peter O'Hanlon
Brian Noyes
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
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.
--