My MVVM rant
As I said in the last post, XAML fans tend to favor the MVVM pattern. I’ve had only limited experience with this, but so far I’m personally not a fan. Let me be blunt. The MVVM projects I’ve seen tend to be over-engineered feats of data-binding hell. If you’ve ever thought, “those bits of ‘glue’ code I have to write are kind of annoying, so why don’t I spend a bunch more time making even more of it,” then this may be the option for you.
Okay, maybe that’s not fair. I’m sure some people make great use of MVVM. Others use the MVC pattern with XAML just fine. Both patterns have the same basic goals of separating your UI stuff from your other stuff, and theoretically making it easier for non-developers to do UI work, or to use fancy tools like Blend to do their UI work, or to build different UIs for different target environments (i.e. adapting to different screen sizes, or making your app feel “at home” on systems with different design conventions).
Personally, I don’t buy it. I get the vision, but I’ve never seen it work. I’ve seen projects crumble under the weight of unnecessary code supporting these patterns, and I’ve seen a lot of cases where development teams start out with a grand MVC vision and end up with a puzzling mash-up of excess components, plumbing gymnastics, and endless cases where someone was in a hurry and just bypassed the whole damn abstraction.
And best of all, I’ve never seen the proposed benefits actually bear fruit. Designers don’t write XAML, and most of these projects end up with exactly one view implementation. Am I wrong? Tell me in the comment section 🙂
Maybe the problem isn’t so much the pattern itself, but the scope at which it’s applied. The projects I’ve seen struggle tend to try and carve these horizontal delineations across an entire codebase. As you’ll see in later Building Great #WinApps posts, I don’t take this approach. While I do separate the UI from the data, I tend to think of the result more as a set of vertically integrated controls, with the necessary interfaces to be composed with each other as the project requires. Maybe it’s just a pedantic philosophical difference. Or maybe you MVVM fans just won’t like the way I build things. Keep following the series if you want to find out!
/rant
Trackbacks & Pingbacks
Comments are closed.
I really like the MVVM pattern and I use the core concepts all the time. However, if something just does not fit into the pattern then I don’t force it.
No-one forces you. I just happen to like the stuff very much and it fits my thinking pattern. What really cranks my style is that this style of thinking is now making inroad on the WEB – Knock, Angular and some other frameworks all promote data in an MV* way, and Knockout in particular allows you a pretty complete analogue of MVVM in XAML.
And any architecture will crumble if people just bypass it. I know have a whole library of reusable code and I can assemble a lot of my GUI using Blend. Drag & drop programming was never so close as with MVVM.
Hi Joost. Yeah I never suggested anyone was forcing anyone else to use MVVM (or MVC, etc). It was more in the context of the last post, where I wax explaining that most people who rave about XAML also very enthusiastically embrace MVVM. I separated out this little rant just because I don’t “get” MVVM. I do get having useful abstractions, avoiding upward dependencies, etc. I mainly just don’t find all the elaborate data-binding to be effective for anything but simple cases. And the examples of MVVM in XAML I’ve seen just make it seem like the pattern gets in the way and makes you write too much code / produce too many objects/events/wiring.
But that’s just my take, which is what you typically find when you read my blog 🙂
MVVM is just a pattern. As a pattern it works remarkably well. It’s the implementations that can be horrendous. I have been on many projects that benefited from MVVM. They were simplified, not complicated. It enabled the designers to work in true parallel with the developers, enabled the development team to scale, and most importantly provided a reusable code base for projects that targeted multiple platforms (such as Windows Phone and Windows Phone 8).
Brandon, I’d suggest you just haven’t been on a project complex enough to require MVVM or perhaps just ones with poor implementations. I definitely have seen it work and when it does works, the developers go “wow, that was easy” not “oh my gosh too much complexity.” I think what happens most often is someone comes along with a stupid rule like “no code behind” when certain things make perfect since, so they write a lot of code just to stick something in the view model that doesn’t belong.
If you don’t have a separate design team or aren’t using design-time data, don’t have a large development team, or aren’t in a situation where the API may be changing as you are developing, it may not be the right pattern but done right I’ve seen it work in countless enterprise projects over the past several years.
Yes! Yes! Yes!!! I’ve been saying this for years.
I don’t disagree. I wish Microsoft would substantially improve how this works by default. But there are WPF MVVM frameworks that help to reduce the plumbing. I personally use Caliburn Micro. Other frameworks I’ve heard of (but don’t really have experience with) are Prism, MVVM Light, and if you’re an Rx freak you might like ReactiveUI.
I’ve used Caliburn Micro for so long that I would have to go to Google to remember how to do MVVM the standard way. It provides convention-based binding between views and view-models. Then when working in your views, it provides conventions to make control binding easier, especially binding actions (like button clicks) to view-model methods.
Why should you even be worried about reducing the plumbing???
Best thing to do is create the object for the whole page in your WCF Service and then bind that object to the page (or dice it up a bit).
Why do you need a bunch of spagetti code that you’ll never re-use.
Much better to unit test the WCF service than the WPF stuff if you’re worried about unit testing.
I agree with you Brandon. It seems as though the technique can work when used with limitation. But a lot of projects I’ve been on (and I’ve been on big ones) are negatively affected by the added complexities of MVVM.
I would definitely add dependency injection and PRISM to that list. I’m not knocking the techniques. I think they are good techniques and have their places. But like you, I’ve been on too many projects where they are misused to the point that the application feels like late-bound spaghetti code. What do I mean by that?
The application still compiles, but at runtime they seem to be plagued with bugs. In many cases they are bugs that wouldn’t exist if I was leveraging the type safety features of C#.
I disagree with one of the commenters notions that if you aren’t using MVVM, then you have spaghetti code. That is a poor concept that doesn’t hold up.
I use partial MVVM. It’s like you say that it can easily grow over complex. So much, that even average developers are stagnant when fixing bugs or adding features.
When your projects seem to have come to a complete halt, or are plagued with bugs that keep coming back, one of these technologies could be the culprit.
Microsoft did a bad job at communicating where to use this technology, what it’s good for, and what are the negative side effects. It’s almost been adopted religiously by developers. Developers, which I noticed, that have no concept of project lifecycles, deadlines and cost.
Great topic!!!