I understand the benefit to unit testing of preferring the view-model over the code-behind. However, I cannot understand the obsession with achieving completely empty code-behinds. At compile time, the code behind and the XAML are combined, so they are actually the same thing. I, to, love using XAML due to its declarative nature which is very cool. But is there actually any practical reason for insisting that all view-related code be XAML rather than C#?
+1
A:
On good reason is that with WPF and XAML, Microsoft aim to keep separated the graphical and coding jobs. In this way, developer and UI designer can work easilly.
Angelodev
2010-07-02 07:58:00
How, specifically, do empty code-behinds aid that collaboration?
HappyNomad
2010-07-02 08:15:54
+3
A:
There are also some benefits in taking advantage of what Blend can do at design-time with XAML but that's really more of a XAML vs (the same code) in code-behind argument. For the no code-behind argument as it relates to MVVM the real goal, as you've pointed out, is to get code moved into classes like ViewModels that can be tested and reused. As with many things, this often gets taken to the extreme and people end up insisting that there never be any code-behind when what is really needed is to have no business logic in code-behind, disregarding that there is also often UI logic too.
XAML is very rich and allows you to do a lot declaratively but there are still UI specific things (i.e. event handlers, some animation handling) that can't be done without using some code. You can usually manage to move this code to some place other than the code-behind by using things like custom controls, attached properties, etc. but if you're not getting any reuse benefits out of doing that it's probably just better to use the code-behind to do that UI logic instead.
Patterns like MVVM are general guiding principles, not a set of strict rules to be obsessively adhered to - those are called programming languages. :)
John Bowen
2010-07-02 13:14:07
If it has to do with the View itself (let's say picking a good color for something based on a value), code-behind is a good place to put it. Sometimes this can be encapsulated, but sometimes it's not worth the effort. This is definitely preferable to putting View-specific things (like colors) into the ViewModel. I think of the 'empty code behind' as mainly advice to help developers think about what they're trying to accomplish, to avoid the temptation of embedding business logic into a click handler, for instance.
Dan Bryant
2010-07-02 17:31:04
+1
A:
It's all about testability. It's hard (nigh impossible) to unit test your code behinds. With MVVM, you can create test harnesses that fully test your Model and ViewModel.
That being said, I'm a fan of being pragmatic. Some UI events are a bear to set up using Commands, and for those, I'll sometimes drop down into the codebehind.
Robaticus
2010-07-02 13:38:31
A:
The view model is the code-behind for the XAML. At least, that's how I think of it. And it's a code-behind file that can be tested without the XAML.
On the other hand, as Ben Johnson might have put it, no man but a fool ever implemented drag and drop in the view model.
Robert Rossney
2010-07-02 17:07:53
The view-model sorta is a code-behind, but not really. One important difference is that it doesn't reference the view. On dnd, you're on the mark that it's view-specific. Better to package it as attached behaviour.
HappyNomad
2010-07-04 16:36:37