1. In XAML as a resource 2. Creation in the view constructor 3. VM is injected into the view (e.g., as constructor parameter) - view sets it as data context/resource 4. External code (e.g., App_Startup) creates the view and the VM and sets it as data context/resource 5. A ServiceLocator pattern 6. Other?
Also interested in things you like and dislike about a particular approach.
For me, it's always been DataContext (1) and either injecting the VM via IOC (3) or through some centralized external code. That might look something like this:
public void ShowView<TView, TViewModel>() { var view = container.Resolve<TView>(); var model = container.Resolve<TViewModel>(); view.DataContext = model; ...
> 1. In XAML as a resource > 2. Creation in the view constructor > 3. VM is injected into the view (e.g., as constructor parameter) - view > sets it as data context/resource > 4. External code (e.g., App_Startup) creates the view and the VM and sets > it as data context/resource > 5. A ServiceLocator pattern > 6. Other?
> Also interested in things you like and dislike about a particular approach.
Yeah. I'm also using ShowView<TV,TVM> like Paul's method in Module class.
If I'm not using IoC, I would create VM instance in XAML,
If we are using Singleton Container like Daniel's framework then we can create a custom markup extension to resolve the VM in XAML. I'm thinking whether it's good idea or not.
>>Creation in the view constructor
Some people in my company used to do that thing. But I more prefer to set DC from external code like ShowView().
Thanks and Best Regards, Michael Sync
Don't go the way life takes you. Take life the way you go
On Sat, Feb 6, 2010 at 6:29 PM, Paul Stovell <p...@paulstovell.com> wrote: > For me, it's always been DataContext (1) and either injecting the VM via > IOC (3) or through some centralized external code. That might look something > like this:
> public void ShowView<TView, TViewModel>() > { > var view = container.Resolve<TView>(); > var model = container.Resolve<TViewModel>(); > view.DataContext = model; > ... > }
> On Sat, Feb 6, 2010 at 8:25 PM, Paul Stovell <p...@paulstovell.com> wrote:
>> Hi Disciples,
>> I just wanted to do a quick poll about wiring up MVVM:
>> First, what do you use to connect the view and view models together?
>> 1. In XAML as a resource >> 2. Creation in the view constructor >> 3. VM is injected into the view (e.g., as constructor parameter) - view >> sets it as data context/resource >> 4. External code (e.g., App_Startup) creates the view and the VM and sets >> it as data context/resource >> 5. A ServiceLocator pattern >> 6. Other?
>> Also interested in things you like and dislike about a particular >> approach.
For concrete implementations, i.e. no IoC, I always define in the XAML as a DataContext, e.g.: <Window.Resources> <local:ConcreteViewModel x:Key="VM" /> </Window.Resources> <Grid DataContext="{StaticResource VM}">
This is just the way I like to define things - it makes it obvious for the designer where things are coming from.
> 1. In XAML as a resource > 2. Creation in the view constructor > 3. VM is injected into the view (e.g., as constructor parameter) - view > sets it as data context/resource > 4. External code (e.g., App_Startup) creates the view and the VM and sets > it as data context/resource > 5. A ServiceLocator pattern > 6. Other?
> Also interested in things you like and dislike about a particular approach.
> For concrete implementations, i.e. no IoC, I always define in the XAML as a > DataContext, e.g.: > <Window.Resources> > <local:ConcreteViewModel x:Key="VM" /> > </Window.Resources> > <Grid DataContext="{StaticResource VM}">
> This is just the way I like to define things - it makes it obvious for the > designer where things are coming from.
> On Sat, Feb 6, 2010 at 10:25 AM, Paul Stovell <p...@paulstovell.com> wrote: > > Hi Disciples,
> > I just wanted to do a quick poll about wiring up MVVM:
> > First, what do you use to connect the view and view models together?
> > 1. In XAML as a resource > > 2. Creation in the view constructor > > 3. VM is injected into the view (e.g., as constructor parameter) - view > > sets it as data context/resource > > 4. External code (e.g., App_Startup) creates the view and the VM and sets > > it as data context/resource > > 5. A ServiceLocator pattern > > 6. Other?
> > Also interested in things you like and dislike about a particular approach.
On Sat, Feb 6, 2010 at 1:20 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote: > That's how I do things too Pete. Maybe IOC could bring some further > extensibility, but I haven't seen the need for it so far.
> On Feb 6, 2:11 pm, "Peter O'Hanlon" <pete.ohan...@gmail.com> wrote: > > For concrete implementations, i.e. no IoC, I always define in the XAML as > a > > DataContext, e.g.: > > <Window.Resources> > > <local:ConcreteViewModel x:Key="VM" /> > > </Window.Resources> > > <Grid DataContext="{StaticResource VM}">
> > This is just the way I like to define things - it makes it obvious for > the > > designer where things are coming from.
> > On Sat, Feb 6, 2010 at 10:25 AM, Paul Stovell <p...@paulstovell.com> > wrote: > > > Hi Disciples,
> > > I just wanted to do a quick poll about wiring up MVVM:
> > > First, what do you use to connect the view and view models together?
> > > 1. In XAML as a resource > > > 2. Creation in the view constructor > > > 3. VM is injected into the view (e.g., as constructor parameter) - view > > > sets it as data context/resource > > > 4. External code (e.g., App_Startup) creates the view and the VM and > sets > > > it as data context/resource > > > 5. A ServiceLocator pattern > > > 6. Other?
> > > Also interested in things you like and dislike about a particular > approach.
I'm using MVVM-Light's approach to bind DataContext to a property exposed by a ViewModelLocator class instantiated as application wide resource.
.Corrado
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Paul Stovell Sent: sabato 6 febbraio 2010 11:25 To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] MVVM binding strategy poll
Hi Disciples,
I just wanted to do a quick poll about wiring up MVVM:
First, what do you use to connect the view and view models together?
1. In XAML as a resource 2. Creation in the view constructor 3. VM is injected into the view (e.g., as constructor parameter) - view sets it as data context/resource 4. External code (e.g., App_Startup) creates the view and the VM and sets it as data context/resource 5. A ServiceLocator pattern 6. Other?
Also interested in things you like and dislike about a particular approach.
Today, Onyx uses a View first approach and connects the two via an attached property (as well as sets the DataContext). I'm moving to ViewModel first, and the attached property will still be used, but it will be read only.
> Secondly, how do you create the view model?
> 1. In XAML as a resource > 2. Creation in the view constructor > 3. VM is injected into the view (e.g., as constructor parameter) - view sets > it as data context/resource > 4. External code (e.g., App_Startup) creates the view and the VM and sets it > as data context/resource > 5. A ServiceLocator pattern > 6. Other?
Today in Onyx if you set View.Model to a Type, it's created during coercion (using DI). Since I'm moving to VM first, it will be created by a ViewModelActivator.
> Also interested in things you like and dislike about a particular approach.
> -- > Paul Stovell
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
I'm using MVVM-Light's approach to bind DataContext to a property exposed by a ViewModelLocator class instantiated as application wide resource.
.Corrado
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Paul Stovell Sent: sabato 6 febbraio 2010 11:25 To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] MVVM binding strategy poll
Hi Disciples,
I just wanted to do a quick poll about wiring up MVVM:
First, what do you use to connect the view and view models together?
1. In XAML as a resource 2. Creation in the view constructor 3. VM is injected into the view (e.g., as constructor parameter) - view sets it as data context/resource 4. External code (e.g., App_Startup) creates the view and the VM and sets it as data context/resource 5. A ServiceLocator pattern 6. Other?
Also interested in things you like and dislike about a particular approach.
I put it in XAML as DataContext if the application architecture allows for it (i.e. no need for the VM's ctor to take parameters). Often I find that VM's are created in code, based on runtime context, and added to the logical tree as a forcing function for a View to be created via typed DataTemplates.
> 1. In XAML as a resource > 2. Creation in the view constructor > 3. VM is injected into the view (e.g., as constructor parameter) - view > sets it as data context/resource > 4. External code (e.g., App_Startup) creates the view and the VM and sets > it as data context/resource > 5. A ServiceLocator pattern > 6. Other?
> Also interested in things you like and dislike about a particular approach.
1. Inject the VM into the View (through an IOC) and set the DC. 2. Use a service which gets the VM and sets the DC. 3. Use an attached property which does the marriage.
When I was on the Prism team we favored more of a VM->First approach where the VM gets the view injected into it, and then immediately sets a "Model" property on the view that was injected, which sets the DC.
> 1. In XAML as a resource > 2. Creation in the view constructor > 3. VM is injected into the view (e.g., as constructor parameter) - view > sets it as data context/resource > 4. External code (e.g., App_Startup) creates the view and the VM and sets > it as data context/resource > 5. A ServiceLocator pattern > 6. Other?
> Also interested in things you like and dislike about a particular approach.
I should add I do like using Jonas' locator in resources method for the blendability benefits. However, outside of that it's not the way I would prefer to go as it adds complexity for the sake of designability. If I could have my cake and eat it too, then VM location would just be a first class member in SL/WPF/Cider/Blend. I would optimally not have to decorate the View / call any imperative code to get the wire-up to happen...it would just "happen". I'll keep dreaming of the day when this is possible.
On Sat, Feb 6, 2010 at 11:55 AM, Glenn Block <glenn.bl...@gmail.com> wrote: > In general I ues on of the following
> 1. Inject the VM into the View (through an IOC) and set the DC. > 2. Use a service which gets the VM and sets the DC. > 3. Use an attached property which does the marriage.
> When I was on the Prism team we favored more of a VM->First approach where > the VM gets the view injected into it, and then immediately sets a "Model" > property on the view that was injected, which sets the DC.
> Lately I find I am favoring 1 and 3 over 2.
> Glenn
> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com>wrote:
>> Hi Disciples,
>> I just wanted to do a quick poll about wiring up MVVM:
>> First, what do you use to connect the view and view models together?
>> 1. In XAML as a resource >> 2. Creation in the view constructor >> 3. VM is injected into the view (e.g., as constructor parameter) - view >> sets it as data context/resource >> 4. External code (e.g., App_Startup) creates the view and the VM and sets >> it as data context/resource >> 5. A ServiceLocator pattern >> 6. Other?
>> Also interested in things you like and dislike about a particular >> approach.
Forgot to mention, the reason I no longer prefer the approach of having the View created as part of injection during the VM creation is because it forces you to dynamically compose your entire UI rather than letting the XAML parser do it for you...hence why you end up having regions in regions in regions.
On Sat, Feb 6, 2010 at 11:58 AM, Glenn Block <glenn.bl...@gmail.com> wrote: > I should add I do like using Jonas' locator in resources method for the > blendability benefits. However, outside of that it's not the way I would > prefer to go as it adds complexity for the sake of designability. If I could > have my cake and eat it too, then VM location would just be a first class > member in SL/WPF/Cider/Blend. I would optimally not have to decorate the > View / call any imperative code to get the wire-up to happen...it would just > "happen". I'll keep dreaming of the day when this is possible.
> On Sat, Feb 6, 2010 at 11:55 AM, Glenn Block <glenn.bl...@gmail.com>wrote:
>> In general I ues on of the following
>> 1. Inject the VM into the View (through an IOC) and set the DC. >> 2. Use a service which gets the VM and sets the DC. >> 3. Use an attached property which does the marriage.
>> When I was on the Prism team we favored more of a VM->First approach where >> the VM gets the view injected into it, and then immediately sets a "Model" >> property on the view that was injected, which sets the DC.
>> Lately I find I am favoring 1 and 3 over 2.
>> Glenn
>> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com>wrote:
>>> Hi Disciples,
>>> I just wanted to do a quick poll about wiring up MVVM:
>>> First, what do you use to connect the view and view models together?
>>> 1. In XAML as a resource >>> 2. Creation in the view constructor >>> 3. VM is injected into the view (e.g., as constructor parameter) - view >>> sets it as data context/resource >>> 4. External code (e.g., App_Startup) creates the view and the VM and sets >>> it as data context/resource >>> 5. A ServiceLocator pattern >>> 6. Other?
>>> Also interested in things you like and dislike about a particular >>> approach.
On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> wrote: > In general I ues on of the following
> 1. Inject the VM into the View (through an IOC) and set the DC. > 2. Use a service which gets the VM and sets the DC. > 3. Use an attached property which does the marriage.
> When I was on the Prism team we favored more of a VM->First approach where > the VM gets the view injected into it, and then immediately sets a "Model" > property on the view that was injected, which sets the DC.
> Lately I find I am favoring 1 and 3 over 2.
> Glenn
> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com> wrote:
>> Hi Disciples,
>> I just wanted to do a quick poll about wiring up MVVM:
>> First, what do you use to connect the view and view models together?
>> 1. In XAML as a resource >> 2. Creation in the view constructor >> 3. VM is injected into the view (e.g., as constructor parameter) - view >> sets it as data context/resource >> 4. External code (e.g., App_Startup) creates the view and the VM and sets >> it as data context/resource >> 5. A ServiceLocator pattern >> 6. Other?
>> Also interested in things you like and dislike about a particular >> approach.
>>hence why you end up having regions in regions in regions.
Maybe, I'm so dumb. I can understand more clearly when I see the code example. Could you please provide the sample? IsShowPopup property of View and updating the view after closing popup can be achieved without having an interface of View in ViewModel...
Thanks and Best Regards, Michael Sync
Don't go the way life takes you. Take life the way you go
> This seems more like Model View Presenter to me?
> Paul
> On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> wrote:
>> In general I ues on of the following
>> 1. Inject the VM into the View (through an IOC) and set the DC. >> 2. Use a service which gets the VM and sets the DC. >> 3. Use an attached property which does the marriage.
>> When I was on the Prism team we favored more of a VM->First approach where >> the VM gets the view injected into it, and then immediately sets a "Model" >> property on the view that was injected, which sets the DC.
>> Lately I find I am favoring 1 and 3 over 2.
>> Glenn
>> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com>wrote:
>>> Hi Disciples,
>>> I just wanted to do a quick poll about wiring up MVVM:
>>> First, what do you use to connect the view and view models together?
>>> 1. In XAML as a resource >>> 2. Creation in the view constructor >>> 3. VM is injected into the view (e.g., as constructor parameter) - view >>> sets it as data context/resource >>> 4. External code (e.g., App_Startup) creates the view and the VM and sets >>> it as data context/resource >>> 5. A ServiceLocator pattern >>> 6. Other?
>>> Also interested in things you like and dislike about a particular >>> approach.
I am saying this is 'not' the approach I prefer any longer, but the one we used in p&p. It is closer to MVP style in terms of hookup. Setting the model property sets the DC on the view.
The approach I prefer is having the VM and View married (through a service) or having the VM injected in to the view.
Michael, that's a different thread :-)
On 2/7/10, Paul Stovell <p...@paulstovell.com> wrote:
> This seems more like Model View Presenter to me?
> Paul
> On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> wrote:
>> In general I ues on of the following
>> 1. Inject the VM into the View (through an IOC) and set the DC. >> 2. Use a service which gets the VM and sets the DC. >> 3. Use an attached property which does the marriage.
>> When I was on the Prism team we favored more of a VM->First approach where >> the VM gets the view injected into it, and then immediately sets a "Model" >> property on the view that was injected, which sets the DC.
>> Lately I find I am favoring 1 and 3 over 2.
>> Glenn
>> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com> wrote:
>>> Hi Disciples,
>>> I just wanted to do a quick poll about wiring up MVVM:
>>> First, what do you use to connect the view and view models together?
>>> 1. In XAML as a resource >>> 2. Creation in the view constructor >>> 3. VM is injected into the view (e.g., as constructor parameter) - view >>> sets it as data context/resource >>> 4. External code (e.g., App_Startup) creates the view and the VM and sets >>> it as data context/resource >>> 5. A ServiceLocator pattern >>> 6. Other?
>>> Also interested in things you like and dislike about a particular >>> approach.
As far as whether it is MVP or not, as I mentioned I believe the key differentiator is that with MVVM the view is directly bound to the ViewModel and talks to the VM through databinding. In MVP, the view is bound to a model hanging off the SupervisingController or not bound at all (passive view).
So whether or not the VM has a reference to the View does not determine it's VMNess......
My $.02
On 2/7/10, Paul Stovell <p...@paulstovell.com> wrote:
> This seems more like Model View Presenter to me?
> Paul
> On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> wrote:
>> In general I ues on of the following
>> 1. Inject the VM into the View (through an IOC) and set the DC. >> 2. Use a service which gets the VM and sets the DC. >> 3. Use an attached property which does the marriage.
>> When I was on the Prism team we favored more of a VM->First approach where >> the VM gets the view injected into it, and then immediately sets a "Model" >> property on the view that was injected, which sets the DC.
>> Lately I find I am favoring 1 and 3 over 2.
>> Glenn
>> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com> wrote:
>>> Hi Disciples,
>>> I just wanted to do a quick poll about wiring up MVVM:
>>> First, what do you use to connect the view and view models together?
>>> 1. In XAML as a resource >>> 2. Creation in the view constructor >>> 3. VM is injected into the view (e.g., as constructor parameter) - view >>> sets it as data context/resource >>> 4. External code (e.g., App_Startup) creates the view and the VM and sets >>> it as data context/resource >>> 5. A ServiceLocator pattern >>> 6. Other?
>>> Also interested in things you like and dislike about a particular >>> approach.
On Sun, Feb 7, 2010 at 10:50 PM, Glenn Block <glenn.bl...@gmail.com> wrote: > As far as whether it is MVP or not, as I mentioned I believe the key > differentiator is that with MVVM the view is directly bound to the > ViewModel and talks to the VM through databinding. In MVP, the view is > bound to a model hanging off the SupervisingController or not bound at > all (passive view).
> So whether or not the VM has a reference to the View does not > determine it's VMNess......
> My $.02
> On 2/7/10, Paul Stovell <p...@paulstovell.com> wrote: > > Hi Glenn,
> >>> where the VM gets the view injected into it, and then immediately sets > a > > "Model" property on the view that was injected
> > This seems more like Model View Presenter to me?
> > Paul
> > On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> > wrote:
> >> In general I ues on of the following
> >> 1. Inject the VM into the View (through an IOC) and set the DC. > >> 2. Use a service which gets the VM and sets the DC. > >> 3. Use an attached property which does the marriage.
> >> When I was on the Prism team we favored more of a VM->First approach > where > >> the VM gets the view injected into it, and then immediately sets a > "Model" > >> property on the view that was injected, which sets the DC.
> >> Lately I find I am favoring 1 and 3 over 2.
> >> Glenn
> >> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com> > wrote:
> >>> Hi Disciples,
> >>> I just wanted to do a quick poll about wiring up MVVM:
> >>> First, what do you use to connect the view and view models together?
> >>> 1. In XAML as a resource > >>> 2. Creation in the view constructor > >>> 3. VM is injected into the view (e.g., as constructor parameter) - view > >>> sets it as data context/resource > >>> 4. External code (e.g., App_Startup) creates the view and the VM and > sets > >>> it as data context/resource > >>> 5. A ServiceLocator pattern > >>> 6. Other?
> >>> Also interested in things you like and dislike about a particular > >>> approach.
I can think of 6 approaches all of which have pros and cons
1. INPC / Property binding 2. Events 3. Messages (Event Aggregator/Messenger/RX framework) 4. Through an intermediary such as a service 5. Through an interface 6. Through delegates (View passes delegates to the VM which it can use to call it back. For example VM might expose a SetActions method which the View calls passing it delegates.
In the MVP case the standard is the Presenter talks back to the view either through an interface, databinding, or through properties in the case of Passive view. With Passive View the properties are not using databinding, instead the view property getters and setters are used to directly set the control value.
> On Sun, Feb 7, 2010 at 10:50 PM, Glenn Block <glenn.bl...@gmail.com>wrote:
>> As far as whether it is MVP or not, as I mentioned I believe the key >> differentiator is that with MVVM the view is directly bound to the >> ViewModel and talks to the VM through databinding. In MVP, the view is >> bound to a model hanging off the SupervisingController or not bound at >> all (passive view).
>> So whether or not the VM has a reference to the View does not >> determine it's VMNess......
>> My $.02
>> On 2/7/10, Paul Stovell <p...@paulstovell.com> wrote: >> > Hi Glenn,
>> >>> where the VM gets the view injected into it, and then immediately sets >> a >> > "Model" property on the view that was injected
>> > This seems more like Model View Presenter to me?
>> > Paul
>> > On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> >> wrote:
>> >> In general I ues on of the following
>> >> 1. Inject the VM into the View (through an IOC) and set the DC. >> >> 2. Use a service which gets the VM and sets the DC. >> >> 3. Use an attached property which does the marriage.
>> >> When I was on the Prism team we favored more of a VM->First approach >> where >> >> the VM gets the view injected into it, and then immediately sets a >> "Model" >> >> property on the view that was injected, which sets the DC.
>> >> Lately I find I am favoring 1 and 3 over 2.
>> >> Glenn
>> >> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com> >> wrote:
>> >>> Hi Disciples,
>> >>> I just wanted to do a quick poll about wiring up MVVM:
>> >>> First, what do you use to connect the view and view models together?
>> >>> Secondly, how do you create the view model?
>> >>> 1. In XAML as a resource >> >>> 2. Creation in the view constructor >> >>> 3. VM is injected into the view (e.g., as constructor parameter) - >> view >> >>> sets it as data context/resource >> >>> 4. External code (e.g., App_Startup) creates the view and the VM and >> sets >> >>> it as data context/resource >> >>> 5. A ServiceLocator pattern >> >>> 6. Other?
>> >>> Also interested in things you like and dislike about a particular >> >>> approach.
Let me think about some scenarios for 6 approaches. I will also listen what other will say about this.. I'm sending some emails to other people who are using MVVM and putting some discussions in a few forums as well. I will discuss with you about the sample and real scenarios for 6 approaches later.. If everyone agree with that then it's cool..
Thanks and Best Regards, Michael Sync
Don't go the way life takes you. Take life the way you go
On Sun, Feb 7, 2010 at 11:29 PM, Glenn Block <glenn.bl...@gmail.com> wrote: > I think it depends.
> I can think of 6 approaches all of which have pros and cons
> 1. INPC / Property binding > 2. Events > 3. Messages (Event Aggregator/Messenger/RX framework) > 4. Through an intermediary such as a service > 5. Through an interface > 6. Through delegates (View passes delegates to the VM which it can use to > call it back. For example VM might expose a SetActions method which the View > calls passing it delegates.
> In the MVP case the standard is the Presenter talks back to the view either > through an interface, databinding, or through properties in the case of > Passive view. With Passive View the properties are not using databinding, > instead the view property getters and setters are used to directly set the > control value.
> Glenn
> On Sun, Feb 7, 2010 at 7:08 AM, Michael Sync <mchls...@gmail.com> wrote:
>> >>Michael, that's a different thread :-)
>> :) yeah. Sorry. :)
>> >>I believe the key differentiator is that with MVVM the view is directly >> bound to the ViewModel and talks to the VM through databinding.
>> View talks to VM thought databinding in MVVM. Okay. Great. Thanks.
>> How does ViewModel talk to View? How does Presenter talk to View?
>> Thanks and Best Regards, >> Michael Sync
>> Don't go the way life takes you. >> Take life the way you go
>> On Sun, Feb 7, 2010 at 10:50 PM, Glenn Block <glenn.bl...@gmail.com>wrote:
>>> As far as whether it is MVP or not, as I mentioned I believe the key >>> differentiator is that with MVVM the view is directly bound to the >>> ViewModel and talks to the VM through databinding. In MVP, the view is >>> bound to a model hanging off the SupervisingController or not bound at >>> all (passive view).
>>> So whether or not the VM has a reference to the View does not >>> determine it's VMNess......
>>> My $.02
>>> On 2/7/10, Paul Stovell <p...@paulstovell.com> wrote: >>> > Hi Glenn,
>>> >>> where the VM gets the view injected into it, and then immediately >>> sets a >>> > "Model" property on the view that was injected
>>> > This seems more like Model View Presenter to me?
>>> > Paul
>>> > On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> >>> wrote:
>>> >> In general I ues on of the following
>>> >> 1. Inject the VM into the View (through an IOC) and set the DC. >>> >> 2. Use a service which gets the VM and sets the DC. >>> >> 3. Use an attached property which does the marriage.
>>> >> When I was on the Prism team we favored more of a VM->First approach >>> where >>> >> the VM gets the view injected into it, and then immediately sets a >>> "Model" >>> >> property on the view that was injected, which sets the DC.
>>> >> Lately I find I am favoring 1 and 3 over 2.
>>> >> Glenn
>>> >> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com> >>> wrote:
>>> >>> Hi Disciples,
>>> >>> I just wanted to do a quick poll about wiring up MVVM:
>>> >>> First, what do you use to connect the view and view models together?
>>> >>> Secondly, how do you create the view model?
>>> >>> 1. In XAML as a resource >>> >>> 2. Creation in the view constructor >>> >>> 3. VM is injected into the view (e.g., as constructor parameter) - >>> view >>> >>> sets it as data context/resource >>> >>> 4. External code (e.g., App_Startup) creates the view and the VM and >>> sets >>> >>> it as data context/resource >>> >>> 5. A ServiceLocator pattern >>> >>> 6. Other?
>>> >>> Also interested in things you like and dislike about a particular >>> >>> approach.
On Sun, Feb 7, 2010 at 7:57 AM, Michael Sync <mchls...@gmail.com> wrote: > Hi Glenn,
> Thanks a lot. Glenn. This is very interesting..
> Let me think about some scenarios for 6 approaches. I will also listen what > other will say about this.. I'm sending some emails to other people who are > using MVVM and putting some discussions in a few forums as well. I will > discuss with you about the sample and real scenarios for 6 approaches > later.. If everyone agree with that then it's cool..
> Thanks and Best Regards, > Michael Sync
> Don't go the way life takes you. > Take life the way you go
> On Sun, Feb 7, 2010 at 11:29 PM, Glenn Block <glenn.bl...@gmail.com>wrote:
>> I think it depends.
>> I can think of 6 approaches all of which have pros and cons
>> 1. INPC / Property binding >> 2. Events >> 3. Messages (Event Aggregator/Messenger/RX framework) >> 4. Through an intermediary such as a service >> 5. Through an interface >> 6. Through delegates (View passes delegates to the VM which it can use to >> call it back. For example VM might expose a SetActions method which the View >> calls passing it delegates.
>> In the MVP case the standard is the Presenter talks back to the view >> either through an interface, databinding, or through properties in the case >> of Passive view. With Passive View the properties are not using databinding, >> instead the view property getters and setters are used to directly set the >> control value.
>> Glenn
>> On Sun, Feb 7, 2010 at 7:08 AM, Michael Sync <mchls...@gmail.com> wrote:
>>> >>Michael, that's a different thread :-)
>>> :) yeah. Sorry. :)
>>> >>I believe the key differentiator is that with MVVM the view is >>> directly bound to the ViewModel and talks to the VM through databinding.
>>> View talks to VM thought databinding in MVVM. Okay. Great. Thanks.
>>> How does ViewModel talk to View? How does Presenter talk to View?
>>> Thanks and Best Regards, >>> Michael Sync
>>> Don't go the way life takes you. >>> Take life the way you go
>>> On Sun, Feb 7, 2010 at 10:50 PM, Glenn Block <glenn.bl...@gmail.com>wrote:
>>>> As far as whether it is MVP or not, as I mentioned I believe the key >>>> differentiator is that with MVVM the view is directly bound to the >>>> ViewModel and talks to the VM through databinding. In MVP, the view is >>>> bound to a model hanging off the SupervisingController or not bound at >>>> all (passive view).
>>>> So whether or not the VM has a reference to the View does not >>>> determine it's VMNess......
>>>> My $.02
>>>> On 2/7/10, Paul Stovell <p...@paulstovell.com> wrote: >>>> > Hi Glenn,
>>>> >>> where the VM gets the view injected into it, and then immediately >>>> sets a >>>> > "Model" property on the view that was injected
>>>> > This seems more like Model View Presenter to me?
>>>> > Paul
>>>> > On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> >>>> wrote:
>>>> >> In general I ues on of the following
>>>> >> 1. Inject the VM into the View (through an IOC) and set the DC. >>>> >> 2. Use a service which gets the VM and sets the DC. >>>> >> 3. Use an attached property which does the marriage.
>>>> >> When I was on the Prism team we favored more of a VM->First approach >>>> where >>>> >> the VM gets the view injected into it, and then immediately sets a >>>> "Model" >>>> >> property on the view that was injected, which sets the DC.
>>>> >> Lately I find I am favoring 1 and 3 over 2.
>>>> >> Glenn
>>>> >> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com> >>>> wrote:
>>>> >>> Hi Disciples,
>>>> >>> I just wanted to do a quick poll about wiring up MVVM:
>>>> >>> First, what do you use to connect the view and view models together?
>>>> >>> Secondly, how do you create the view model?
>>>> >>> 1. In XAML as a resource >>>> >>> 2. Creation in the view constructor >>>> >>> 3. VM is injected into the view (e.g., as constructor parameter) - >>>> view >>>> >>> sets it as data context/resource >>>> >>> 4. External code (e.g., App_Startup) creates the view and the VM and >>>> sets >>>> >>> it as data context/resource >>>> >>> 5. A ServiceLocator pattern >>>> >>> 6. Other?
>>>> >>> Also interested in things you like and dislike about a particular >>>> >>> approach.
On Mon, Feb 8, 2010 at 12:01 AM, Glenn Block <glenn.bl...@gmail.com> wrote: > I am working on a blog post on this as we speak (write)
> On Sun, Feb 7, 2010 at 7:57 AM, Michael Sync <mchls...@gmail.com> wrote:
>> Hi Glenn,
>> Thanks a lot. Glenn. This is very interesting..
>> Let me think about some scenarios for 6 approaches. I will also listen >> what other will say about this.. I'm sending some emails to other people who >> are using MVVM and putting some discussions in a few forums as well. I will >> discuss with you about the sample and real scenarios for 6 approaches >> later.. If everyone agree with that then it's cool..
>> Thanks and Best Regards, >> Michael Sync
>> Don't go the way life takes you. >> Take life the way you go
>> On Sun, Feb 7, 2010 at 11:29 PM, Glenn Block <glenn.bl...@gmail.com>wrote:
>>> I think it depends.
>>> I can think of 6 approaches all of which have pros and cons
>>> 1. INPC / Property binding >>> 2. Events >>> 3. Messages (Event Aggregator/Messenger/RX framework) >>> 4. Through an intermediary such as a service >>> 5. Through an interface >>> 6. Through delegates (View passes delegates to the VM which it can use to >>> call it back. For example VM might expose a SetActions method which the View >>> calls passing it delegates.
>>> In the MVP case the standard is the Presenter talks back to the view >>> either through an interface, databinding, or through properties in the case >>> of Passive view. With Passive View the properties are not using databinding, >>> instead the view property getters and setters are used to directly set the >>> control value.
>>> Glenn
>>> On Sun, Feb 7, 2010 at 7:08 AM, Michael Sync <mchls...@gmail.com> wrote:
>>>> >>Michael, that's a different thread :-)
>>>> :) yeah. Sorry. :)
>>>> >>I believe the key differentiator is that with MVVM the view is >>>> directly bound to the ViewModel and talks to the VM through databinding.
>>>> View talks to VM thought databinding in MVVM. Okay. Great. Thanks.
>>>> How does ViewModel talk to View? How does Presenter talk to View?
>>>> Thanks and Best Regards, >>>> Michael Sync
>>>> Don't go the way life takes you. >>>> Take life the way you go
>>>> On Sun, Feb 7, 2010 at 10:50 PM, Glenn Block <glenn.bl...@gmail.com>wrote:
>>>>> As far as whether it is MVP or not, as I mentioned I believe the key >>>>> differentiator is that with MVVM the view is directly bound to the >>>>> ViewModel and talks to the VM through databinding. In MVP, the view is >>>>> bound to a model hanging off the SupervisingController or not bound at >>>>> all (passive view).
>>>>> So whether or not the VM has a reference to the View does not >>>>> determine it's VMNess......
>>>>> My $.02
>>>>> On 2/7/10, Paul Stovell <p...@paulstovell.com> wrote: >>>>> > Hi Glenn,
>>>>> >>> where the VM gets the view injected into it, and then immediately >>>>> sets a >>>>> > "Model" property on the view that was injected
>>>>> > This seems more like Model View Presenter to me?
>>>>> > Paul
>>>>> > On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> >>>>> wrote:
>>>>> >> In general I ues on of the following
>>>>> >> 1. Inject the VM into the View (through an IOC) and set the DC. >>>>> >> 2. Use a service which gets the VM and sets the DC. >>>>> >> 3. Use an attached property which does the marriage.
>>>>> >> When I was on the Prism team we favored more of a VM->First approach >>>>> where >>>>> >> the VM gets the view injected into it, and then immediately sets a >>>>> "Model" >>>>> >> property on the view that was injected, which sets the DC.
>>>>> >> Lately I find I am favoring 1 and 3 over 2.
>>>>> >> Glenn
>>>>> >> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com> >>>>> wrote:
>>>>> >>> Hi Disciples,
>>>>> >>> I just wanted to do a quick poll about wiring up MVVM:
>>>>> >>> First, what do you use to connect the view and view models >>>>> together?
>>>>> >>> Secondly, how do you create the view model?
>>>>> >>> 1. In XAML as a resource >>>>> >>> 2. Creation in the view constructor >>>>> >>> 3. VM is injected into the view (e.g., as constructor parameter) - >>>>> view >>>>> >>> sets it as data context/resource >>>>> >>> 4. External code (e.g., App_Startup) creates the view and the VM >>>>> and sets >>>>> >>> it as data context/resource >>>>> >>> 5. A ServiceLocator pattern >>>>> >>> 6. Other?
>>>>> >>> Also interested in things you like and dislike about a particular >>>>> >>> approach.
I think there's a lot of overlap and at the end of the day it comes down to preference. The big delineation is can it be handled through binding or not? In the case of "not" there are a range options (the 5)
On Sun, Feb 7, 2010 at 8:01 AM, Glenn Block <glenn.bl...@gmail.com> wrote: > I am working on a blog post on this as we speak (write)
> On Sun, Feb 7, 2010 at 7:57 AM, Michael Sync <mchls...@gmail.com> wrote:
>> Hi Glenn,
>> Thanks a lot. Glenn. This is very interesting..
>> Let me think about some scenarios for 6 approaches. I will also listen >> what other will say about this.. I'm sending some emails to other people who >> are using MVVM and putting some discussions in a few forums as well. I will >> discuss with you about the sample and real scenarios for 6 approaches >> later.. If everyone agree with that then it's cool..
>> Thanks and Best Regards, >> Michael Sync
>> Don't go the way life takes you. >> Take life the way you go
>> On Sun, Feb 7, 2010 at 11:29 PM, Glenn Block <glenn.bl...@gmail.com>wrote:
>>> I think it depends.
>>> I can think of 6 approaches all of which have pros and cons
>>> 1. INPC / Property binding >>> 2. Events >>> 3. Messages (Event Aggregator/Messenger/RX framework) >>> 4. Through an intermediary such as a service >>> 5. Through an interface >>> 6. Through delegates (View passes delegates to the VM which it can use to >>> call it back. For example VM might expose a SetActions method which the View >>> calls passing it delegates.
>>> In the MVP case the standard is the Presenter talks back to the view >>> either through an interface, databinding, or through properties in the case >>> of Passive view. With Passive View the properties are not using databinding, >>> instead the view property getters and setters are used to directly set the >>> control value.
>>> Glenn
>>> On Sun, Feb 7, 2010 at 7:08 AM, Michael Sync <mchls...@gmail.com> wrote:
>>>> >>Michael, that's a different thread :-)
>>>> :) yeah. Sorry. :)
>>>> >>I believe the key differentiator is that with MVVM the view is >>>> directly bound to the ViewModel and talks to the VM through databinding.
>>>> View talks to VM thought databinding in MVVM. Okay. Great. Thanks.
>>>> How does ViewModel talk to View? How does Presenter talk to View?
>>>> Thanks and Best Regards, >>>> Michael Sync
>>>> Don't go the way life takes you. >>>> Take life the way you go
>>>> On Sun, Feb 7, 2010 at 10:50 PM, Glenn Block <glenn.bl...@gmail.com>wrote:
>>>>> As far as whether it is MVP or not, as I mentioned I believe the key >>>>> differentiator is that with MVVM the view is directly bound to the >>>>> ViewModel and talks to the VM through databinding. In MVP, the view is >>>>> bound to a model hanging off the SupervisingController or not bound at >>>>> all (passive view).
>>>>> So whether or not the VM has a reference to the View does not >>>>> determine it's VMNess......
>>>>> My $.02
>>>>> On 2/7/10, Paul Stovell <p...@paulstovell.com> wrote: >>>>> > Hi Glenn,
>>>>> >>> where the VM gets the view injected into it, and then immediately >>>>> sets a >>>>> > "Model" property on the view that was injected
>>>>> > This seems more like Model View Presenter to me?
>>>>> > Paul
>>>>> > On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> >>>>> wrote:
>>>>> >> In general I ues on of the following
>>>>> >> 1. Inject the VM into the View (through an IOC) and set the DC. >>>>> >> 2. Use a service which gets the VM and sets the DC. >>>>> >> 3. Use an attached property which does the marriage.
>>>>> >> When I was on the Prism team we favored more of a VM->First approach >>>>> where >>>>> >> the VM gets the view injected into it, and then immediately sets a >>>>> "Model" >>>>> >> property on the view that was injected, which sets the DC.
>>>>> >> Lately I find I am favoring 1 and 3 over 2.
>>>>> >> Glenn
>>>>> >> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com> >>>>> wrote:
>>>>> >>> Hi Disciples,
>>>>> >>> I just wanted to do a quick poll about wiring up MVVM:
>>>>> >>> First, what do you use to connect the view and view models >>>>> together?
>>>>> >>> Secondly, how do you create the view model?
>>>>> >>> 1. In XAML as a resource >>>>> >>> 2. Creation in the view constructor >>>>> >>> 3. VM is injected into the view (e.g., as constructor parameter) - >>>>> view >>>>> >>> sets it as data context/resource >>>>> >>> 4. External code (e.g., App_Startup) creates the view and the VM >>>>> and sets >>>>> >>> it as data context/resource >>>>> >>> 5. A ServiceLocator pattern >>>>> >>> 6. Other?
>>>>> >>> Also interested in things you like and dislike about a particular >>>>> >>> approach.
>> In the case of "not" there are a range options (the 5)
Yeah. But I'm wondering if there is any other way like using DP or attached property instead of having an interface of View in ViewModel. I think I need to take some times to understand the need. It would be really great if you can add some real scenarios (and also samples) for 6 approaches (esp: 2, 5, 6 ) in your blog post.
Thanks a lot, Glenn.
Thanks and Best Regards, Michael Sync
Don't go the way life takes you. Take life the way you go
On Mon, Feb 8, 2010 at 12:02 AM, Glenn Block <glenn.bl...@gmail.com> wrote: > I think there's a lot of overlap and at the end of the day it comes down to > preference. The big delineation is can it be handled through binding or not? > In the case of "not" there are a range options (the 5)
> On Sun, Feb 7, 2010 at 8:01 AM, Glenn Block <glenn.bl...@gmail.com> wrote:
>> I am working on a blog post on this as we speak (write)
>> On Sun, Feb 7, 2010 at 7:57 AM, Michael Sync <mchls...@gmail.com> wrote:
>>> Hi Glenn,
>>> Thanks a lot. Glenn. This is very interesting..
>>> Let me think about some scenarios for 6 approaches. I will also listen >>> what other will say about this.. I'm sending some emails to other people who >>> are using MVVM and putting some discussions in a few forums as well. I will >>> discuss with you about the sample and real scenarios for 6 approaches >>> later.. If everyone agree with that then it's cool..
>>> Thanks and Best Regards, >>> Michael Sync
>>> Don't go the way life takes you. >>> Take life the way you go
>>> On Sun, Feb 7, 2010 at 11:29 PM, Glenn Block <glenn.bl...@gmail.com>wrote:
>>>> I think it depends.
>>>> I can think of 6 approaches all of which have pros and cons
>>>> 1. INPC / Property binding >>>> 2. Events >>>> 3. Messages (Event Aggregator/Messenger/RX framework) >>>> 4. Through an intermediary such as a service >>>> 5. Through an interface >>>> 6. Through delegates (View passes delegates to the VM which it can use >>>> to call it back. For example VM might expose a SetActions method which the >>>> View calls passing it delegates.
>>>> In the MVP case the standard is the Presenter talks back to the view >>>> either through an interface, databinding, or through properties in the case >>>> of Passive view. With Passive View the properties are not using databinding, >>>> instead the view property getters and setters are used to directly set the >>>> control value.
>>>> Glenn
>>>> On Sun, Feb 7, 2010 at 7:08 AM, Michael Sync <mchls...@gmail.com>wrote:
>>>>> >>Michael, that's a different thread :-)
>>>>> :) yeah. Sorry. :)
>>>>> >>I believe the key differentiator is that with MVVM the view is >>>>> directly bound to the ViewModel and talks to the VM through databinding.
>>>>> View talks to VM thought databinding in MVVM. Okay. Great. Thanks.
>>>>> How does ViewModel talk to View? How does Presenter talk to View?
>>>>> Thanks and Best Regards, >>>>> Michael Sync
>>>>> Don't go the way life takes you. >>>>> Take life the way you go
>>>>> On Sun, Feb 7, 2010 at 10:50 PM, Glenn Block <glenn.bl...@gmail.com>wrote:
>>>>>> As far as whether it is MVP or not, as I mentioned I believe the key >>>>>> differentiator is that with MVVM the view is directly bound to the >>>>>> ViewModel and talks to the VM through databinding. In MVP, the view is >>>>>> bound to a model hanging off the SupervisingController or not bound at >>>>>> all (passive view).
>>>>>> So whether or not the VM has a reference to the View does not >>>>>> determine it's VMNess......
>>>>>> My $.02
>>>>>> On 2/7/10, Paul Stovell <p...@paulstovell.com> wrote: >>>>>> > Hi Glenn,
>>>>>> >>> where the VM gets the view injected into it, and then immediately >>>>>> sets a >>>>>> > "Model" property on the view that was injected
>>>>>> > This seems more like Model View Presenter to me?
>>>>>> > Paul
>>>>>> > On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> >>>>>> wrote:
>>>>>> >> In general I ues on of the following
>>>>>> >> 1. Inject the VM into the View (through an IOC) and set the DC. >>>>>> >> 2. Use a service which gets the VM and sets the DC. >>>>>> >> 3. Use an attached property which does the marriage.
>>>>>> >> When I was on the Prism team we favored more of a VM->First >>>>>> approach where >>>>>> >> the VM gets the view injected into it, and then immediately sets a >>>>>> "Model" >>>>>> >> property on the view that was injected, which sets the DC.
>>>>>> >> Lately I find I am favoring 1 and 3 over 2.
>>>>>> >> Glenn
>>>>>> >> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell <p...@paulstovell.com> >>>>>> wrote:
>>>>>> >>> Hi Disciples,
>>>>>> >>> I just wanted to do a quick poll about wiring up MVVM:
>>>>>> >>> First, what do you use to connect the view and view models >>>>>> together?
>>>>>> >>> Secondly, how do you create the view model?
>>>>>> >>> 1. In XAML as a resource >>>>>> >>> 2. Creation in the view constructor >>>>>> >>> 3. VM is injected into the view (e.g., as constructor parameter) - >>>>>> view >>>>>> >>> sets it as data context/resource >>>>>> >>> 4. External code (e.g., App_Startup) creates the view and the VM >>>>>> and sets >>>>>> >>> it as data context/resource >>>>>> >>> 5. A ServiceLocator pattern >>>>>> >>> 6. Other?
>>>>>> >>> Also interested in things you like and dislike about a particular >>>>>> >>> approach.
On Sun, Feb 7, 2010 at 8:09 AM, Michael Sync <mchls...@gmail.com> wrote: > Hi Glenn,
> >> In the case of "not" there are a range options (the 5)
> Yeah. But I'm wondering if there is any other way like using DP or attached > property instead of having an interface of View in ViewModel. I think I need > to take some times to understand the need. It would be really great if you > can add some real scenarios (and also samples) for 6 approaches (esp: 2, > 5, 6 ) in your blog post.
> Thanks a lot, Glenn.
> Thanks and Best Regards, > Michael Sync
> Don't go the way life takes you. > Take life the way you go
> On Mon, Feb 8, 2010 at 12:02 AM, Glenn Block <glenn.bl...@gmail.com>wrote:
>> I think there's a lot of overlap and at the end of the day it comes down >> to preference. The big delineation is can it be handled through binding or >> not? In the case of "not" there are a range options (the 5)
>> On Sun, Feb 7, 2010 at 8:01 AM, Glenn Block <glenn.bl...@gmail.com>wrote:
>>> I am working on a blog post on this as we speak (write)
>>> On Sun, Feb 7, 2010 at 7:57 AM, Michael Sync <mchls...@gmail.com> wrote:
>>>> Hi Glenn,
>>>> Thanks a lot. Glenn. This is very interesting..
>>>> Let me think about some scenarios for 6 approaches. I will also listen >>>> what other will say about this.. I'm sending some emails to other people who >>>> are using MVVM and putting some discussions in a few forums as well. I will >>>> discuss with you about the sample and real scenarios for 6 approaches >>>> later.. If everyone agree with that then it's cool..
>>>> Thanks and Best Regards, >>>> Michael Sync
>>>> Don't go the way life takes you. >>>> Take life the way you go
>>>> On Sun, Feb 7, 2010 at 11:29 PM, Glenn Block <glenn.bl...@gmail.com>wrote:
>>>>> I think it depends.
>>>>> I can think of 6 approaches all of which have pros and cons
>>>>> 1. INPC / Property binding >>>>> 2. Events >>>>> 3. Messages (Event Aggregator/Messenger/RX framework) >>>>> 4. Through an intermediary such as a service >>>>> 5. Through an interface >>>>> 6. Through delegates (View passes delegates to the VM which it can use >>>>> to call it back. For example VM might expose a SetActions method which the >>>>> View calls passing it delegates.
>>>>> In the MVP case the standard is the Presenter talks back to the view >>>>> either through an interface, databinding, or through properties in the case >>>>> of Passive view. With Passive View the properties are not using databinding, >>>>> instead the view property getters and setters are used to directly set the >>>>> control value.
>>>>> Glenn
>>>>> On Sun, Feb 7, 2010 at 7:08 AM, Michael Sync <mchls...@gmail.com>wrote:
>>>>>> >>Michael, that's a different thread :-)
>>>>>> :) yeah. Sorry. :)
>>>>>> >>I believe the key differentiator is that with MVVM the view is >>>>>> directly bound to the ViewModel and talks to the VM through databinding.
>>>>>> View talks to VM thought databinding in MVVM. Okay. Great. Thanks.
>>>>>> How does ViewModel talk to View? How does Presenter talk to View?
>>>>>> Thanks and Best Regards, >>>>>> Michael Sync
>>>>>> Don't go the way life takes you. >>>>>> Take life the way you go
>>>>>> On Sun, Feb 7, 2010 at 10:50 PM, Glenn Block <glenn.bl...@gmail.com >>>>>> > wrote:
>>>>>>> As far as whether it is MVP or not, as I mentioned I believe the key >>>>>>> differentiator is that with MVVM the view is directly bound to the >>>>>>> ViewModel and talks to the VM through databinding. In MVP, the view >>>>>>> is >>>>>>> bound to a model hanging off the SupervisingController or not bound >>>>>>> at >>>>>>> all (passive view).
>>>>>>> So whether or not the VM has a reference to the View does not >>>>>>> determine it's VMNess......
>>>>>>> My $.02
>>>>>>> On 2/7/10, Paul Stovell <p...@paulstovell.com> wrote: >>>>>>> > Hi Glenn,
>>>>>>> >>> where the VM gets the view injected into it, and then immediately >>>>>>> sets a >>>>>>> > "Model" property on the view that was injected
>>>>>>> > This seems more like Model View Presenter to me?
>>>>>>> > Paul
>>>>>>> > On Sun, Feb 7, 2010 at 5:55 AM, Glenn Block <glenn.bl...@gmail.com> >>>>>>> wrote:
>>>>>>> >> In general I ues on of the following
>>>>>>> >> 1. Inject the VM into the View (through an IOC) and set the DC. >>>>>>> >> 2. Use a service which gets the VM and sets the DC. >>>>>>> >> 3. Use an attached property which does the marriage.
>>>>>>> >> When I was on the Prism team we favored more of a VM->First >>>>>>> approach where >>>>>>> >> the VM gets the view injected into it, and then immediately sets a >>>>>>> "Model" >>>>>>> >> property on the view that was injected, which sets the DC.
>>>>>>> >> Lately I find I am favoring 1 and 3 over 2.
>>>>>>> >> Glenn
>>>>>>> >> On Sat, Feb 6, 2010 at 2:25 AM, Paul Stovell < >>>>>>> p...@paulstovell.com> wrote:
>>>>>>> >>> Hi Disciples,
>>>>>>> >>> I just wanted to do a quick poll about wiring up MVVM:
>>>>>>> >>> First, what do you use to connect the view and view models >>>>>>> together?
>>>>>>> >>> Secondly, how do you create the view model?
>>>>>>> >>> 1. In XAML as a resource >>>>>>> >>> 2. Creation in the view constructor >>>>>>> >>> 3. VM is injected into the view (e.g., as constructor parameter) >>>>>>> - view >>>>>>> >>> sets it as data context/resource >>>>>>> >>> 4. External code (e.g., App_Startup) creates the view and the VM >>>>>>> and sets >>>>>>> >>> it as data context/resource >>>>>>> >>> 5. A ServiceLocator pattern >>>>>>> >>> 6. Other?
>>>>>>> >>> Also interested in things you like and dislike about a particular >>>>>>> >>> approach.
