Is it wrong to put the ViewModel in codebehind?

Question

In MVVM, we normally have a View (XAML + usually empty codebehind) as well as a ViewModel that is a separate class. Interaction between View and ViewModel takes place via data binding.

Assuming the View is just XAML and its codebehind is empty (which is usually the case), is there anything wrong with using the codebehind itself as the ViewModel and binding the View to properties of the codebehind? The separation of concerns is still there - you have a pure XAML view and a ViewModel which is the codebehind, and they communicate with each other only via data binding. The ViewModel can still be unit-tested.

This may sound like heresy, but I can't think of any use cases that would justify having to create separate classes for the ViewModel when the codebehind is in fact empty.

Answer 1

The definition of code-behind is code that is associated with the view. In XAML, this is usually done via the x:Class attribute on the XAML root element, inheriting from the base type of the root element (this is always specified in auto-generated partial class files), and so on. There's actually a little section in the documentation that outlines the concept of code-behind in WPF XAML. Since the x:Class attribute only lets you specify one class, this basically ties your XAML markup to exactly one class. That class represents its code-behind.

Since code-behind is essentially view logic, or the underlying code for the XAML markup, you cannot make a code-behind class a view model. View models are completely view-agnostic except for the fact that they provide data to and receive data from their associated views through data binding; code-behind or UI logic on the other hand is primarily concerned with providing behavior to view objects represented by the XAML, and not application logic.

Like others have said, if you can somehow make it work then it's not "wrong" as far as the compiler is concerned, but I would say that's kind of going against the nature of code-behind.

Answer 2

If it works, it isn't wrong.

However, MVVM is a pattern and patterns are there for a reason. We put view models in separate classes to enforce MVVM's key principle - separation of concerns(SoC). SoC has a cultural impact on your development - you and your team are less likely to get the two mixed up.

Contrary to the statement in your question, you are not allowing separation.

Here is a use case for you: By putting the view model in code behind, you are no longer able to hot-swap the view that is used to represent your view model and you will find this restrictive.

It is worth remembering that all patterns are tools. They are a means, not an end and you should not break your back to use them. There is wiggle room but in this case, I feel you are wiggling too far.