When does it make sense to abandon MVVM?

Question

As I've been learning WPF, I've been concentrating on applying only the MVVM pattern to applications.

However, I notice that for some functionality such as validation, it is difficult or impossible to remain true to the MVVM model. Many times simply sticking an x:Name on an element and changing it in code-behind event-handler solves the problem immediately.

What real world experience do you have with abandoning the MVVM pattern?

• when does abandoning MVVM make sense? e.g. have you developed rules that if an application is of a certain complexity you will use it, otherwise you won't?
• when does it abandoning MVVM cripple you later (e.g. I can imagine if you want to upgrade your application to use Composite Application Library, the whole concept of injecting ViewModels and the Container won't work if you have all your logic in code behind
• when does abbandoning MVVM not matter, e.g. I can imagine that code that you don't want/need to have tested can just be in the code behind while your basic structure is still MVVM and gets run through mock tests, etc.

Answer 1

I think code-behind is fine if it's view related only. It doesn't break MVVM because it's the separation of the layers what is important. If your VMs stay unaware of the Views, then I don't think it matters if you used XAML or code. You try to minimize code-behind because it's usually cleaner and easier to do in XAML, but sometimes a few lines of code are cleaner than a lot of XAML. For example, binding all the keys of the keyboard. You can type 101 key bindings in XAML or 5 lines of code.