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 haven't abandon the MVVM pattern because I never fully apply it!

Due to a historical background, my company still use C native libs, encapsulated in managed libs, used in C# and WPF programs. Bindings can't be used, and some behaviors such as INotifyPropertyChanged can't be implemented because changes are done in some deep C method... Refactoring so deeply isn't an option!

So on one hand, i understand that MVVM can be painful to strictly follow.

On the other hand, IMHO i think MVVM is a good pattern for WPF and should be used as often as possible.

Answer 2

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.

Answer 3

I've not yet run into anything that's impossible to do following MVVM. Some things are difficult, yes, but once a solution is found, the difficulty is gone. Any time you run into something that's difficult, remember your two "big guns" in this pattern: attached behaviors and services. With these two concepts firmly under your control, there's nothing that you can do with codebehind that you can't do in a cleaner, MVVM friendly, manner. The tricky part here is just in finding the best, most reusable, design... but that's true in any code.

When does abandoning MVVM make sense? That depends on your definition of abandoning, but the simple answer is never. If you've got a specific issue your struggling with and don't have the time to find a clean solution, then the pragmatic thing to do is abandon the pattern for that one problem area, not entirely as your complexity example suggests.

When does it abandoning MVVM cripple you later? When you have to maintain the application.

When does abbandoning MVVM not matter? Demo/sample programs, throw away/simple utilities and the like.

Answer 4

MVVM is just a recommendation. If you do not like, you do not have to use it. A lot of its claimed advantages are still need proof. But you can always borrow some good ideas from it though.