I’m currently trying to get my head round MVVM for WPF – I don’t mean get my head round the concept, but around the actual nuts and bolts of doing anything that is further off the beaten track than dumb CRUD.
What I’ve noticed is that lots of the frameworks, and most/all blog posts are from ‘ages’ ago.
Is this because it is now old hat and the bloggers have moved onto the Next Big Thing, or just because they’ve said everything there is to say?
In other words, is there something I’m missing here?
1
MVVM isn’t outdated, but it was overplayed to begin with. I never liked it and it kept me in WinForms for too long; failing to see the forest for the trees, I threw the baby out with the bathwater. I get WPF now, and I get the idea of not wanting to mix code with markup, but I prefer the Android style of sticking the markup in one place and dereferencing it with casts in my code (which you can also do in WPF, even though it never got trendy to do so for whatever reason).
That way you gain more fine-grained control and don’t have to worry about all the “onchanged” handling everywhere. I feel this is actually more testable because tests won’t always catch it if you miss an “onchanged” event.
You lose a bit of “declarative”-ness, which seems to be a trend these days (e.g. if two widgets are mapped to the same value, in MVVM you can just do that, whereas with imperative code you have to set both individually). But even with MVVM, that only works in the menial case. If some widget has to display the log of another widget, then you’ve got to write another handler and another “onchanged” event and so you end up having to stretch the definition of “declarative” to say it is so.
2015 update
WPF MVVM was (r)evolutionary for its time. As was WPF. But they both had their warts. Plain WPF had too much built into it (plus it was built on XML), and was kind of a pain to deal with. (Really, if WPF had just taken a more “library” approach rather than a “framework” approach, it could have turned into some really cool stuff and the whole tech universe might be entirely different now). The idea of MVVM was great, but trying to fit an MVVM into WPF was somewhat hacky since 1) C# couldn’t really express it without a lot of boilerplate, and 2) WinForms relics like modal popups were still ideologically prevalent but couldn’t be easily represented in MVVM. Thus it all sucked.
That said, it’s still the only realistic option on Windows when you need transparency or GPU for LOB apps.
React has of course made MVVM obsolete. I was disappointed that VS2015 didn’t have a native counter to that. For now we’re still stuck using raw WPF (which is OK, but feels old (really feels just as old as winforms now), and doesn’t have a ton of built-in functionality (feels like some cool but abandoned project) or with-MVVM, which at this point feels like much overhead for nothing, since even good MVVM (angular 1) has been exposed for its shortcomings.
I’d avoid WPF MVVM. It’s an extra layer, and nobody is caring about it anymore.
6
All said and done, there is a limit to what you can do with an MVVM framework.
They are “done” since WPF has not moved on since Microsoft released it. If there were updates to the technology, the libraries would need updating too. This has not happened.
12