Millions of bloggers give thanks to their software gods by offering tips on how to use this magical beast, hoping that these same gods will look kindly upon them and deliver the software they crave. The less clever among them heap scorn on the gods and wait for a mystical MVVM tome that will explain their every confusion and answer all questions on this mystical pattern.
So lets get back to reality...
Over the last 17 years I have developed a truckload of GUI applications using a wide range of languages from assembler and C++ through to Winforms and WPF. I have also created several complicated multi threaded silverlight and WPF Apps using MVVM, I was pragmatic and used it only when it made sense and when it is worthy of my time. I too was tempted by its claims, but not any more.
It is my considered opinion that if MVVM could be erased from space and time we would all be producing better applications and in general be a lot happier.
The MVVM pattern was designed to try and accommodate the flawed XAML concept which was naively put forward by Microsoft all those years ago. They had big plans to replace HTML with this stuff, big plans which are now a distant memory.
WPF is dead!
Its been hanging on for grim death for years but MVVM has ripped open its chest and let the world see the true horror that is hidden within. It has laid bare the evil black magic that must be carved into XAML to make MVVM work. This pattern is the final dagger in WPF's barely beating heart.
MVVM asks you to create untyped XML files that contain free text view model names, property links, black magic bindings, mystical triggers, obscure commands, baffling templates and untraceable style overrides.
Then in the 'real' code you create notification properties with untyped string names, cross your fingers observable collections, even more magical routed events and commands and then pray to the gods you can make it all link together.
As I write this blasphemy I can hear the impassioned cries of 'Testability!' and 'Separation of concerns!'. Wondrous tails of a soon to be future where designers and developers live in a perfect world of magical collaboration and mutual respect. Its within our grasp they cry!
Sorry guys, you have all been led down the garden path on this one.
MVVM and WPF basically produces unmaintainable code as soon as the application gets even slightly complex. XAML is the problem, all these binding features MVVM forces you to use are at best an Alpha in WPF, and because WPF is such a sprawling mess of legacy 'features' it wont be fixed ever.
Trying to fix bugs in someone else's MVVM screen is nigh on impossible because its so hard to decipher the flow of control. When you make changes most of the time you only get runtime errors instead of compile time. Debugging these runtime errors is painful as they are generally hidden in the black magic of bindings or triggers or some other crazy abstraction in XAML.
MVVM testability claims are dubious at best. If you breakdown your frontend code correctly you can test it pretty well anyway, you dont need MVVM for that.
Also the mantra that XAML lets designers design and developers code is flawed. It sounds great but in practice any slightly complicated screen basically needs a developer to make such complicated XAML that its sticky taped together just to work, and as soon as a designer tries to load it into blend or edit manually. Kaboom!
Finally, MVVM produces terrible performance. It is nearly impossible to see where the bottle necks are as all rendering is done via black magic bindings and triggers. Trying to get any WPF application running smoothly is a struggle but using MVVM makes it even worse. As have I often said during WPF development, 'My old C64 scrolled smoother than this and it only had 38k of available memory'
If you insist on still using this pattern remember this.
MVVM is a sharp tool, be very careful or you will cut yourself.
 |
| GCS Wiz |
