WPF: Where does MVVM stop and code-behind begins?

Question

I have created a Window which has a ListView to display a collection of persons. There are also 3 TextBoxes that are supposed to display person's first and last name, and an age. Finally, there's a Button to save the new person data entered in those TextBoxes.

Loading persons into the ListView is done by implementing MVVM. Works like a charm! Also, adding new people to the collection by clicking the Button is also done through MVVM.

But there are two use cases that I am not sure whether it is wiser to use commands, i.e. MVVM, or just plain code-behind. The use cases are:

1. When user selects a person from the ListView, the TextBoxes should show the person details.
2. When user types types characters instead of digits in the TextBox that displays person's age, she or he should be warned that the entered data is incorrect.

The reason why I am in doubt whether I should use MVVM or code-behind is because both use cases are related to view only (GUI), i.e. there is no interactivity with the model or application business logic. The ListView item source is bound to a collection of persons ObservableColleciton<Person> and all data related to the selected person is already passed to the view when the ListView is populated with items. In the second use case, again, there is no need to go to ViewModel in order to let it fire the message box about the wrong user input. How about creating a validation callback in the age dependency property of the ViewModel class instead?

Thanks for all clarifications.

Answer 1

The textboxes can and should definitely be populated through bindings in XAML when the ListView selection changes, eg:

<ListView Name="people" .../>

<TextBox Text="{Binding ElementName=people, Path=SelectedItem.FirstName}"/>

Or to reduce coding, put the text boxes in their own panel with a DataContext set, eg:

<Grid DataContext="{Binding ElementName=people, Path=SelectedItem}">
    <TextBox Text="{Binding Path=FirstName}"/>
    <TextBox Text="{Binding Path=LastName}"/>
</Grid>

Validation can be hooked-up in XAML, but the code that does the validating is typically implemented in a class. There's a convenient abstract class in System.Windows.Controls called ValidationRule that can be used to quickly create a validator. See this blog post for an example.

Answer 2

The only time I start dropping code into the code-behind files is when I cannot put it in the ViewModel or deeper in the object graph.

For example, you're first situation is, as mentioned above by C. Lawrence Wenham, completely solvable in XAML code. There is no need to resort to the code-behind to achieve this effect. And this example can be expanded to interactions with a collection that isn't necessarily presented in a control like a listbox. You can write XAML code the responds to changes in the current item in a collection in the ViewModel via binding.

Your second situation can also achieved through dvalidation facilities within the ViewModel and databinding to those facilities with your XAML. IDataErrorInfo is a great mechanism that is built in for just this purpose. Here is a nice little article demonstrating a simple use of IDataErrorInfo.

Examples of when you have to drop into code-behind are hopefully few and far between. One example I've encountered is when a control does not support ICommand and you can not bind functionality to a behavioral element, an example control being a ListBox. But there are some techniques to get around this limitation, as demonstrated in this great SO question. Also, in the event that you need to override rendering in custom controls, you'll need to do this in code-behind or in an inherited class.

Hope this adds a bit more useful information to the answers.