MVVM binding strategy poll

[Paul Stovell]

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. DataContext
2. View-level resource (e.g., Window.Resources)
3. Application-level resource (Application.Resources)
4. ObjectDataProvider
5. Other?

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.

--
Paul Stovell

[Paul Stovell]

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;
   ...
}

--
Paul Stovell

[Michael Sync]

>>Secondly, how do you create the view model?

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

http://michaelsync.net

[Peter O'Hanlon]

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.

--
Peter O'Hanlon

[Daniel Vaughan]

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.

[Peter O'Hanlon]

We are of one mind - it's like some form of Vulcan Mind Meld.

--
Peter O'Hanlon

[Corrado Cavalli]

I’m using MVVM-Light’s approach to bind DataContext to a property exposed by a ViewModelLocator class instantiated as application wide resource.

 

.Corrado

[Bill Kempf]

On Sat, Feb 6, 2010 at 5:25 AM, Paul Stovell <pa...@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. DataContext
> 2. View-level resource (e.g., Window.Resources)
> 3. Application-level resource (Application.Resources)
> 4. ObjectDataProvider
> 5. Other?

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.

[Laurent Bugnion]

Me too (obviously), unless this is a super simple demo app, in which case i do what Pete showed with the VM in the Window/UC's resources.

In the future i want to experiment a bit and make the ViewModelLocator a bit more like a factory.

Cheers,
Laurent
--
Sent from mobile

-original message-
Subject: RE: [WPF Disciples] MVVM binding strategy poll
From: "Corrado Cavalli" <corrado...@gmail.com>
Date: 06.02.2010 14:48

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-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Paul Stovell
Sent: sabato 6 febbraio 2010 11:25
To: wpf-di...@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. DataContext
2. View-level resource (e.g., Window.Resources)
3. Application-level resource (Application.Resources)
4. ObjectDataProvider
5. Other?

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.

--
Paul Stovell

[Josh Smith]

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.

Josh

[Glenn Block]

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 <pa...@paulstovell.com> wrote:

[Glenn Block]

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.

[Glenn Block]

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.

 

Glenn

[Paul Stovell]

Hi Glenn,

>> where the VM gets the view injected into it, and then immediately sets a "Model" property on the view that was injected

So something like:

public EditCustomerViewModel(IEditCustomerView view)

{

    view.Model = this; // ?

}

This seems more like Model View Presenter to me? 

Paul

--
Paul Stovell

[Michael Sync]

Hi Glenn,

I agreed with Paul. 

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

http://michaelsync.net

[Glenn Block]

Hi Paul

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

--
Sent from my mobile device

[Glenn Block]

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

--

[Michael Sync]

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

http://michaelsync.net

[Glenn Block]

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

[Michael Sync]

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

http://michaelsync.net

[Glenn Block]

I am working on a blog post on this as we speak (write)

[Michael Sync]

Hi Glenn,

Great.. Thanks, Glenn. I'm looking forward to read your post. Thanks. 

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Glenn Block]

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)

[Michael Sync]

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

http://michaelsync.net

[Glenn Block]

When you say DPs, are you mean the VM inherits from DependencyObject? Or are you saying the VM gets DPs passed into it that it uses to talk back?

[Michael Sync]

>>are you mean the VM inherits from DependencyObject?

No. 

>> are you saying the VM gets DPs passed into it that it uses to talk back?

Yeah. 

But I didn't think about the real use case yet. but I'm still thinking that there should be a way to avoid having an interface of View. But yes, I might be wrong tho. I'm thinking about pro/con and use cases of your 6 approaches, man.. :)  Thanks for sharing.. Those are interesting things that make me re-think about pattern.. Thanks. 

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Glenn Block]

I don't think DPs solve the problem. Think of the second set of solutions as a way to invoke some method on the view, and perform a transient action, you are not changing it's state (necessarily). It's a very targetted "Do This" rather then "Change to this". The state of the View may very likely be the same before and after the invocation has occurred. You might be able to address a subset through DPs, but my guess is it will get very messy and non-intuitive quickly. Also think of the idea of return value such as a func. How will that work?

 

Glenn

[Michael Sync]

>>a way to invoke some method on the view

I'm not clear with this. Why do we have some methods in the view? 

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Glenn Block]

It depends on the complexity of the UI interaction.

[Michael Sync]

Thanks. What I heard from Blend team is that Blend is the tool that designers can create the UI, Animation and interaction... 

Anyway, Can we use Blend Behivor or something instead of writing some methods in View? What level of complexity are you talking about? 

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Glenn Block]

You could possibly use events combined with blend behaviors. There's always options. All I am saying is there are several different ways to skin a cat, and one is having a reference to the view through an interface.

Glenn

[Glenn Block]

Alot of it depends on whether or not you have a designer in your org or not. There are plenty of shops where there is no designer, and no one is using Blend. In those cases I've seen a lean toward the more view code-oriented approaches.

[Michael Sync]

Okay.

 

>>You could possibly use events combined with blend behaviors. There's always options. All I am saying is there are several different ways to skin a cat, and one is having a reference to the view through an interface

 

Yeah. But I would call it as MVP-style MVVM.

 

After thinking about those approaches for hours, I got some questions.

 

The following things can be used in Presenter as well.

 

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.

 

Question 1: Am I correct in saying that the following the differences between MVP and MVVM?

 

1. View talks to ViewModel via binding. In MVP, View directly calls the Presenter.

2. ViewModel has INPC / Property binding while Presenter doesn't have. Presenter set the value to the property of control directly.

 

Only two differences.

 

Question 2: Why can't View call ViewModel directly since we can write some codes in code-behind for complex UI?

 

View

 

var viewModel = (MyViewModel)this.DataContext;

view.DoSomething();

 

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Glenn Block]

There's a ton of options (including not using a VM at all). "Rightness" is in the eye of the beholder. My point is to look at pros and cons of each. As a side note, I just had a really rich discussion with Ward Bell on this, and it seems like there is a seventh option which leverages Databinding.

 

The canonical scenerio I will use is a job processing system. Each job has it's own view and receives will a tick notification that occurs based on a long running asynch operation that the Job VM initiates. As the operation occurs, it sends periodic notifications back to the VM. These notifications are not progress based, but rather indicate that work is being done. So the challenge is for the VM to notify it's view that the work is being done. The notification is targetted in that there could be multiple views open which each receive their own specific notifications.

 

Glenn

[Jeremiah Morrill]

Why'd you guys stop!  This is pretty good stuff :)!

I'll say that I practice M-V-PVM (Dunno what we are calling it).  There is an overall attempt to do do things with first with binding, behaviors, commands, and this covers most of my needs...but if I have to jump through hoops (like making non-reusable or over complicated solutions) to stay pure, communication via interfaces is my general fallback.  When I'm opening up my IV/IVM interfaces, my biggest concern with view-code-behind is, how blendable is it?  Does it hide or complicate a designer's ability to use it?

We can solve a lot with Blend behaviors, mediators and maybe custom controls, but relying on all for everything, I imagine, could have maintenance pains.  Just imagine a Blend designer being faced with hundreds of behaviors in their pallet.  Or a developer having to managed mountains of "mediator message" definitions.  (I suppose you could say the same thing about having mountains of interfaces)  Sometimes opening up an interface is just a good solution to a simple problem.

IMHO,

-Jer

[Glenn Block]

I worked on a blog post for about 4 hrs (on this) then took a break :-)

That included a nice long discussion with Ward and a few Laurent interruptions.

Blog post pedning....

On 2/7/10, Jeremiah Morrill <jeremiah...@gmail.com> wrote:
> Why'd you guys stop! This is pretty good stuff :)!
>

> I'll say that I practice *M-V-PVM (*Dunno what we are calling it). There is

> an overall attempt to do do things with first with binding, behaviors,

> commands, and this covers *most* of my needs...but if I have to jump through

> hoops (like making non-reusable or over complicated solutions) to stay pure,
> communication via interfaces is my general fallback. When I'm opening up my
> IV/IVM interfaces, my biggest concern with view-code-behind is, how
> blendable is it? Does it hide or complicate a designer's ability to use it?
>
> We can solve a lot with Blend behaviors, mediators and maybe custom
> controls, but relying on all for everything, I imagine, could
> have maintenance pains. Just imagine a Blend designer being faced with
> hundreds of behaviors in their pallet. Or a developer having to
> managed mountains of "mediator message" definitions. (I suppose you could
> say the same thing about having mountains of interfaces) Sometimes opening

> up an interface is just a *good *solution to a simple problem.

>>> *View*

[Michael Sync]

Good morning! 

>>There's a ton of options (including not using a VM at all)

Great. In my case, I used MVVM pattern that doesn't include V or VM or M in my project. My colleague asked me why I call it MVVM even we don't even have anything like View or VM or M. I told him that I just love the name.  :) Just kidding.  We are discussing for so long, right? so we need some laughs.  :) Okay. Get back to the topic.. 

Are we still discussing about MVVM pattern? I'm very interested to see how you will show us the sample of MVVM pattern that doesn't include a ViewModel. 

>>Sometimes opening up an interface is just a good solution to a simple problem.

Yeah. I agree with that. Because I did use the same thing in my project once. I was using Infragistic Datagrid with DataSet (Actually, we need dynamic columns but we don't have time to create DataSet-Alike or anything. That's why we used DataSet to bind the Infragistic Datagrid. ) The problem was that Datagrid doesn't change the column if we change the DataSet that binded to that datagird. So, the workaround was that i added an interface of VIew in ViewModel and passed the dataset to View. Then, changed the columns at code-behinded. 

But I informed the team that due to this problem and our resource/time, I will use the combination of MVP and MVVM. As I mentioned before, we can combine or modify the pattern based on the need of your project. but it should not be like my fish lives in water but your fish lives in tree.. 

>>The canonical scenerio I will use is a job processing system. Each job has it's own view and receives will a tick notification that occurs based on a long running asynch operation that the Job VM initiates. As the operation occurs, it sends periodic notifications back to the VM. These notifications are not progress based, but rather indicate that work is being done. So the challenge is for the VM to notify it's view that the work is being done. The notification is targetted in that there could be multiple views open which each receive their own specific notifications.

I think it's just a event pub/sub.

Here is one scenerio. 

I will use Data Template instead of User Control in this scenerio. 

When I was working for Sport Gambling platform (My ex-company was developing a platforum for sport gambling and casino.), there was a listing that shows the danger of each event. We are using this listing to monitor how many people and how much money are betting for each game. If people are betting so much amount for a particular game then we need to be notificed so that we can cover the amount to other gambling company. 

What I used there was that I created Data Template for each event. Each DataTemplate has two panels. One is for normal Event and another is for "Danger Event".  The visiblity will be binded to the property of Event Object. And then, I'm showing the list of DataTemplate in my event list. If the betting amount reaches the danger level, the messaging service (we used RTI ) will push the notification to the client. then, I changed the property of Event object so the look and feel of Event Data Template will be changed. It was WPF application and I didn't use Visual State Manager for that case. 

There is another scenerio. 

The view has VSM that show "Loading" state and "Loaded" state. As we were sharing the code between Silverlight 2 and WPF at that time, all of our service calls are async.. We set "Loading" state to View before calling async service. and we set "Loaded" states after completing the service. 

Note: If I refer to previous conversation, my view has "Change To This" only instead of "Do This()". 

Question #3: Is the data-binding a must for MVVM? 

If the answer for Question #2 is 'Yes' and 'No' for Question #3 then we can say that MVP and MVVM are the same except we prefer to have binding and INP. But binding and INP are not the requirement of MVVM. Presenter can be a ViewModel as soon as we change the name.

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Laurent Bugnion]

There go the 2 hours you had planned for that ;)
--
Sent from mobile

[Glenn Block]

My point was you don't HAVE to use MVVM, that in itself is an option ;-)

 

Glenn

[Glenn Block]

Well I did stop after 4. Will resume tomorrow. This will be one of those loooooooooooooong posts. If it wasn't for Michael asking for sample code, I'd be done hours ago :-)

[Michael Sync]

>>My point was you don't HAVE to use MVVM, that in itself is an option ;-)

Then, I totally agree with it. :)  

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Michael Sync]

>>This will be one of those loooooooooooooong posts. If it wasn't for Michael asking for sample code, I'd be done hours ago :-)

Thanks, man. .I really appreciate it. 

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Bill Kempf]

Using Dependency Injection or Service Location the designer doesn't
have to write any code.

I'll go back to Onyx again. We'll stick with the current Onyx design,
so that you can see things in action. We'll start with something
simple: being able to display a message. The designer doesn'tpe do a
thing. The developer uses the View.Activated event to register an
IDisplayMessage with the view. In fact, the framework does this for
you if you want the default behavior of displaying a message box, and
you'll only need to register a different service implementation if you
want to change that behavior. This can be done based on the Type of
the view. The ViewModel then uses the IView (which inherits
IServiceProvider) to obtain the IDisplayMessage service. The ViewModel
is entirely decoupled from any specific view, and remains testable,
while the designer's workflow wasn't impacted and he need not write a
line of code.

In Onyx V2, things remain very similar, but the IDisplayMessage will
be injected via the ViewModel's constructor instead of using Service
Location. This means that IView will no longer be an IServiceProvider,
and instead this service exists solely to deal with
Show/ShowModal/Close operations, which are important when going with a
ViewModel first design.

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

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