Tight Coupling between View and ViewModel

Aug 3, 2010 at 10:32 PM

Hi Josh

I just recently bought your MVVM book and must say it been very helpful and interesting so far. I'm a WPF developer out on the field and as I'm reading your code and source code, I can't help but notice that the views have a tight coupling to the view models, e.g. the BubbleBurstView creates a BubbleBurstViewModel in the Xaml. I didn't think one would let the views have a reference to the view models in such a manner, perhaps using an interface to the view models would be more suitable. One would need to have loose coupling like in situations when you would have to have a plug-in architecture, or want to use a "different" library of view models for whatever reasons, or just following good design.

I'm sure you must have your reasons, and I'm also actively learning more about MVVM, and trying to find ways to build a good design, so I'm very keen to hear your views on this.

Cheers

Ed

Coordinator
Aug 4, 2010 at 3:08 PM

Hi Ed,

In my mind, the tight coupling between a View and ViewModel is found in the binding paths.  Binding paths require the View to have knowledge of the ViewModel's property names.  There have been some attempts to ease the pain of this coupling, such as T4 templates that analyze XAML to find binding paths that contain invalid property names, but the problem is inescapable. 

The coupling that you point out, where Views reference ViewModels, is not necessarily a bad thing.  Having a VM reference a View is usually a no-no, since it reduces testability and skinability.  But Views always implicitly reference VMs, via their DataContext (or through other means).  Explicitly referencing a VM from the code-behind of a View is just building upon the implicit VM dependency a View already has. 

You wrote: "One would need to have loose coupling like in situations when you would have to have a plug-in architecture, or want to use a "different" library of view models for whatever reasons, or just following good design."

I agree with the plug-in architecture and different library points, but disagree with the "following good design" point.  If BubbleBurst needed to support a plug-in VM architecture, I definitely would not have hard-coded VM creation code into Views.  But I didn't need that, which is why I disagree with the "following good design" comment.  In fact, I think that the phrase itself is meaningless.  You cannot follow good design, you must discover it.

I hope this has been helpful.

Thanks for buying and reading my book. :)

Josh

P.S. Rules exist for those who need them.

Aug 4, 2010 at 10:11 PM

Hi Josh

thanks for the detailed reply, it has given me a lot to think about. I really like your P.S. bit...heheheh.

 

About this statement, "Having a VM reference a View is usually a no-no, since it reduces testability and skinability", I'm not too sure about how skinability works, but how does that affect a VM's testability. Surely you can mock it if the view has an interface.

 

If possible I'd like to get you expertise on the work I'm doing ATM.

On the project that I'm on, we use Unity as a DI container, and we have our VMs get a hold of the view via its interface in the VM's constructor, and perform a view.DataContext = this. We don't hold on to the View's reference in the VM. As much as possible, we try not to let our view's have a reference to the VMs, in some cases where it's not possible, we break that "rule". The idea is that the view can communicate to the VM via DataBinding and Commands. At least for as long as I remember that was what was preached to me since I started WPF, SL and MVVM, guidelines like "View code behind should be empty"...etc. You get the gist :)

 

I would love to hear your opinion on this. I like to hear what people have to say,  the more I gather, the more I learn. Thanks again for your time Josh. BTW I really enjoy your blog, has helped me understand lots of WPF concepts. I As a fellow blogger, I can appreciate you contribution back to the community. Keep it going!

Cheers

Ed

 

 

 

Coordinator
Aug 5, 2010 at 2:48 PM

I don't have an opinion on this, to be honest.  If that approach solves the problem, without creating a worse problem, then it sounds like a good plan.  I'm not fanatical about the details.

Josh