What are the problems of the MVVM pattern?
Here's a good, short blog post on the advantages and disadvantages of MVVM, straight from John Gossman himself.
His main disadvantages are:
"For simple UI, M-V-VM can be overkill. In bigger cases, it can be hard to design the ViewModel up front in order to get the right amount of generality. Data-binding for all its wonders is declarative and harder to debug than nice imperative stuff where you just set breakpoints"
To build our application, we started with MVVM, but after having much of problems we gave up on MVVM because of following reasons which will identify where not to use MVVM.
Inheritance Problem
We program in .NET, and we use C# and best we sure want Inheritance. C# does not support multiple class inheritance, so we can not have abstract classes with logic that will partially be reused in UI as well as logic.
Most of the time we are confused, how to design View Models so that we can inherit and control the logic.
If we inherit View, we can not inherit ViewModel same time, and if we inherit ViewModel then we can not inherit View at the same time. Instead we have to use very complicated generics and with help of tools like Prism and Unity we can achieve, but it is not worth the time.
ViewModel to ViewModel Binding
Well most of time business logic isnt that simple like A=B+C, UI and Response on UI plays a huge part. However we can bind UI's visual properties to View Model's data properties, but question comes on how to actually bind one view model to another view model, and if they go through two bindings of shared controls, then we have no idea of what will be executed first.
ViewModel is not simple replacement of CodeBehind
It is assumed that ViewModel is simple replacement of CodeBehind files. But while making our app, restriction on inheritance taught us that as it is WPF/Silverlight supports UI Style that can completely separate UI with logic, we are just over separating business logic in ViewModel.
Repeated Code in ViewModel
We eventually realized that we are just writing same pattern of code in every View and every ViewModel, changing which becomes a huge pain, and maintaining is a pain too. MVVM is more suitable for test driven development but when it comes to writing extensible components, they are not the best candidate.
WPF/Silverlight already lets you separate code and UI very nicely, we indeed now have designed very simple class hierarchy that performs business logic and give us all that we need. We now create all ICommand based command properties as dependency properties of our classes, that we bind within UserControl as well as Templated Control.
ICommand in CodeBehind or Template and Styles in ResourceDictionary gives us almost all benefits of what we can get over MVVM.
It is a great pattern and frankly one of the few flushed UI out patterns for WPF. What I mean by that is that many people understand and have adopted it. Therefore it's relatively easy to get help and information on it.
The biggest downside in my opinion is that it increases the number of classes and components in your application, because SRP trumps DRY in this pattern. That being said, I think it is worth it.
Yes, it's an overkill for small hello world-style applications.