Is Model-View-ViewModel the best pattern to use in WPF? Are there any downsides?
Disadvantages of MVVM Model:This can confuse the developer and make the development or debugging process complicated. When it comes to an Android environment, the user is restricted with only two ways to work with View. Moreover, they can either use Data Binding or any other View method.
The Model-View-ViewModel (MVVM) pattern helps to cleanly separate the business and presentation logic of an application from its user interface (UI).
MVVM – short for Model-View-ViewModel – is an architecture pattern that takes advantage of user device capabilities and browser memory to improve application performance.
Getting this to work is difficult. In order to benefit from the MVVM pattern, you have to distribute code in several places throughout the layers of your application. You also have to use esoteric programming constructs like templates and lamba expressions. Stuff that makes you stare at the screen scratching your head.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With