views:

280

answers:

4

Hello,

In MVP pattern, a Presenter has an interface of View so the presenter can call iview.DoSomething().. What about in MVVM pattern?

According to John Gossman's UML diagram http://blogs.msdn.com/johngossman/archive/2006/04/13/576163.aspx , ViewModel doesn't have an interface of View. So, seems like the ViewModel and View should be communicated via Binding only. (or use attached property or blend bahiovr or etc).

What do you guys think?

+1  A: 

The whole purpose of MVVM is to vastly reduce the amount of code in your code-behind class of your WPF form or user control. The idea is that anything that would be handled by the view in classic MVC/MVP can be translated over to the VM by using a combination of data binding and/or commands. In my general usage of MVVM I have managed to completely remove all of the code-behind in my forms/user controls and the VM has no direct knowledge of the view it is controlling. If you have a situation that really cant be handled by data binding or a command then please elaborate on your initial question and I (or one of the many, many more talented MVVM'ers on here) will try to point you in the right direction.

Leom Burke
Thanks. The question is ~ Do you think that having an interface of View in ViewModel violates the MVVM pattern? Example: IPersonView, PersonView and PersonViewModel.. and PersonViewModel has IPersonView...
Michael Sync
Hi sorry missed the comment and see you that you accepted Stians answer but for completeness here is my reply. I do think that it violates the MVVM pattern (in my understanding) and as has now mentioned using data binding through exposed properties is the way to update the view. Glad you got an answer though :)
Leom Burke
Thanks, man... Actually, your post answered me as well but the problem here is that i can't mark more than one post as answered.As there is no standard rule and no owner/creator for MVVM pattern, we need to ask everyone whether we all agree on that or not.. :) That's why I'm asking the question about MVVM in different communities and write the summarized information in one of my post..
Michael Sync
+3  A: 

I agree with John Gossman. The way the ViewModel "talks" to the View is through Bindings only. In fact - the ViewModel shouldn't care about the View at all. It should simply make data available through properties, and it's up to the View to decide what it will dynamically bind to in the ViewModels. If the ViewModel wants to tell the View something this should occur implicit through Bindings.

A similar question was asked an hour ago - here.

stiank81
Thanks a lot. I agreed with that as well. when I was writing this post http://michaelsync.net/2010/02/03/rules-of-mvvm , some said that it's okay to have the interface of view in ViewModel. I told them that it will be a MVP pattern. of course, we can mix the patterns but I think having an interface of View in VM violate the MVVM pattern.. Thanks for your answer.. I really appreciate it.
Michael Sync
Sounds like you're on the right track. Glad to be of help. Will check out your blog post! :-)
stiank81
Thanks. please let me know if you have any comment or suggestion for that post.. :)
Michael Sync
Nice post :-) One thing I like is that I can have the Model classes all clean - not adding stuff there just because it is needed by the View. E.g. I don't have to keep some list sorted just because the View wants it sorted - that's up the the ViewModel to handle. But you've covered this to by saying that the Model can be plain DTO.
stiank81
Thanks, Stain.. The most of people agreed with all facts (except one) that I mentioned about MVVM in that post.. The only one thing that people didn't agree that some people think that they can have an interface of view in ViewModel.
Michael Sync
A: 

It typically does - through events on INotifyProperty changed, if nothing else.

kyoryu
I'm sorry. I didn't get you.. Are you talking about having an interface of View in VM?
Michael Sync
Assuming you're talking C#, the events exposed on the INotifyPropertyChanged interface are typically listened to (via data binding) by the View. Data binding isn't really magic - it's just hooking up handlers to events on INotifyPropertyChanged and INotifyCollectionChanged.But yeah, I'd say that typically the VM does talk to the View, to inform it of data changes. It has an idea of an *abstract* view, though, and not a particular implementation - its communication should be limited to "this changed" and not "so change this control"
kyoryu
Yes.. So, "this changed" limitation = Data Binding, right? :)
Michael Sync
Yeah :) But I don't actually see a problem with other types of commmunication, so long as it's basically data being sent, and no knowledge of the view leaks through. Others may be more purist than me :)
kyoryu
A: 

Can a ViewModel talk to View in MVVM pattern?

Answer: Yes, but in a decoupled way. It’s allowed to introduce an interface IView for the communication.

The MVVM pattern is about to move the logic from the View into the ViewModel. This way we are able to unit test this logic.

More information can be found here: WPF Application Framework (WAF)

.

Best Regards

jbe

jbe
I looked at WAF long time back. I saw that the creator of WAF set the password in code behind in Demo. Not sure why he do that. >>Yes, but in a decoupled way.So, what would be the differences between MVP and MVVM pattern? We can move the logic to Presenter in MVP too. Do you think that it's okay to set iview.DoSomething from ViewModel?
Michael Sync
From the point of view of decoupling and testability it is definitely allowed to call IView.DoSomething from the ViewModel. If you use Binding instead then you define a property of the ViewModel. So the View knows about the property of the ViewModel. It’s just that Binding uses Reflection (not type safe) but the coupling is the same.
jbe
for decoupling and testability, we don't even need to use MVVM pattern. MVC or MVP or etc are testable as well. I still have two questions. 1) If you said that it's okay to have an interface of View in ViewModel. Can you tell me the differences between MVP or MVVM? You can also read my discussion with Glenn in this link http://groups.google.com/group/wpf-disciples/browse_thread/thread/7588c66f21fb82af as well. 2) Do you think it is okay to do ((ViewModel)this.DataContext).DoThat() in View too?
Michael Sync
jbe
MVVM = PresentationModel. but if one can do ((ViewModel)this.DataContext).DoThat() then why people are creating the attached property or blend behivor.. if you look other people's reply then the most of people believe that the communication between View and VM is binding onnly..
Michael Sync
That’s the point. A lot people believe that MVVM is about zero lines of code in the code-behind file. This might have advantages for designer / developer workflow. However, if you care only about coupling and testability then “var name = ((ViewModel)this.DataContext.Name” is the same as “{Binding Path=Name}”. Binding retrieves also the Name property from DataContext – why should this be different?
jbe
The differences between MVP and MVVM pattern is that View and ViewModel talks via Binding. This is the main reason why they added the attached property or Blend Behavior into the framework. Otherwise, we don't even need MVVM. We can simply stick with MVP. I worked with CAB and SCSF frameworks for years. I'm sure that MVP pattern works very well. but we need to sync the data between V and P. We don't want that. So, Binding is the way to remove manual synchronization.
Michael Sync