WPF/Silverlight Programmers: Is MVVM Overkill?

Question

I just have mixed feelings about MVVM. It seems I need to code so much to get the most remedial things to work. I miss events (commanding is such a pain), binding everything leads to a debug nightmare, and I miss having a reference to the view!

I was just wondering about your feelings of MVVM vs the plain old code behind way. What do you like better and/or what do you normally use or recommend using?

Thanks

Answer 1

I'm definitely in the minority on this one, but I tend to agree with @Shnitzel. MVVM, and the binding that goes hand-in-hand with it, are great ideas, but they're poorly served by the current MS tools. The syntax for all but the simplest bindings is very difficult to get right, and is made much harder by the fact that WPF and Silverlight silently swallow all the errors. (Yes, some of the errors show up in the debug window, but not enough of them, and without enough detail.) You can use hacks like writing a debug value converter, but the fact remains that the toolset is still pretty immature. (And then there's my standard complaint, that data binding isn't strongly typed, which means that the tools CAN'T catch the errors for you.)

I hear everyone when they insist on testability, and I'm a big fan of automated testing. But at least with the current state of our tooling, MVVM's improved testability comes at a pretty big price.

Consider this scenario: you've got a large app with 50+ forms/pages, and you've just engaged in a major refactoring of your Model and ViewModel. In the process, you renamed a bunch of classes and properties, etc. Now find every place in your XAML that you need to change to reflect the new class and property names. So much for testability, eh? Not only will the IDE not catch your binding mistakes, the compiler won't catch them, and, best of all, the app won't even throw an error at runtime. You have to get a tester to run through the whole app, and make sure that all your bindings are still doing what you want them to do. Ugggh. Ugly and painful. At least when I was doing things the old-fashioned way, the compiler would tell me when I misspelled something.

Going back into my cave to avoid the slings and arrows quickly headed my way...

[Edit 12/10/2010 - MS recently announced that SL5 would have the ability to debug data bindings, including the ability to set breakpoints on them, so you could see what's going on. This is a big step in the right direction. It still doesn't fix what I see as the fundamental problem, that databinding doesn't have compile-time type checking, but it improves the usefulness of the toolset quite a bit.]

Answer 2

People have mentioned testing, which is a good point. Another point in my opinion is reuseability, bind the same viewmodel to different views. E.g maybe you have a simplified view for some users and a more advanced one for others.

I see people mentioning how handling of events is a pain and such. There are MVVM frameworks which handles this. In my opinion it's also acceptable to hook event handlers to code-behind and call methods on the viewmodel from code-behind. It's certainly better than not be using MVVM because of the hard times people may have hooking up events.

Another HUGE advantage lies in the nature of the MVVM, separation of GUI and business logic. If you work with designers, they are all up in the XAML world, talking about gradients, borders, shading and what not. While you, the programmer happily codes away on your ViewModel with unit-tests. So when the designer has a prototype ready, it's just a matter of hooking up the commands, and bindings. Easy piecy GUI ready =)

Answer 3

The whole thing is, IMHO, a bunch of super-tech marketing hype, and in the long run will serve NO purpose other than to drive development to where development costs can bear the burden of the loss of productivity... i.e., off-shore. It is murdurously S-L-O-W to create a functional UI that does ANYTHING. As if all apps are simple pages of content, shopping carts, or data grids. Too bad. So -- if an app that has a few bugs that get ironed out over a few release cycles is so bad, we'll just trade that off for a system that no one person can possibly understand the end-to-end overall picture... for what? Testability? What a bunch of complete crap. As if the days of bugs and fixes are what, gone? Ya, right... my test says 2 + 2 = 4, therefore my app is bug-free. Right.

Iterative development will come back, mark my words. As soon as the true costs of TDD become more obvious when compared to production of SOME functionality, needed ASAP.