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.]