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

Now, some here use the MVVM and are fine with it. Some are not since they are lifting most of the dev tasks and are not in some big projects with said designers, testers and more. However, I have been in both and have seen both ways. There are people which jump on any pattern and must implement it, no matter what. Even small applications in order to manage some small data are being developed in MVVM and more. They will be scheduled and planned for weeks, even though some of those programs could be hacked out in a few days, but the patterns and testing and more must be fulfilled. And honest: many developers learn by doing and some of those patterns are extremely overwhelming because they combine so many patterns and abstract programming techniques.

Answer 2

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

Answer 4

The truth is that many people don't use unit testing. And yet, there is still good reason to use MVVM. I would point out that this keeps the business logic out of the UI. Also, if you have similar views you can use the same view model for both of them.

I also like that I can make huge changes to the UI while not having to touch my logic. Or, I can easily add in more logic without touching my UI. For instance, I have changed from a list to a combobox and not had to touch the code.

As for the commanding, it was a tough point for me for a long time. Then I discovered the RelayCommand in MVVM Light. With that it is quite simple to setup a method to fire with the command. Personally I almost never make use of the parameter option on my commands. I prefer to only make use of state inside of the viewmodel.

Answer 5

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 6

MVVM has its pain points - like all the boilerplate code needed for commanding, messing with the binding syntax and the incredibly stupid hacks need to close a form.

-- but --

This is all due to lack of a good framework - this video was the big eye opener for me, if you pick the right framework it can take care of all the nasty parts automatically (and if you can't find a good framework writing your own mini-framework that solves your pain points is easier than dealing with "naked" MVVM).

Just look at that video and see how with a good small framework you can write MVVM apps with less code than the alternative.

Answer 7

From Josh Smith's article on MVVM:

In addition to the WPF (and Silverlight 2) features that make MVVM a natural way to structure an application, the pattern is also popular because ViewModel classes are easy to unit test. When an application's interaction logic lives in a set of ViewModel classes, you can easily write code that tests it. In a sense, Views and unit tests are just two different types of ViewModel consumers. Having a suite of tests for an application's ViewModels provides free and fast regression testing, which helps reduce the cost of maintaining an application over time.

For me, this is the most important reason to use MVVM.

Before, I would have controls which mashed the view and viewmodel together. But a view essentially has mouse and keyboard events as input, and drawn pixels as output. How do you unit test or integration test something like that? MVVM makes this problem go away as it separates the untestable view from the testable viewmodel, and keeps the view layer as thin as possible.

Answer 8

The usefulness of a MVVM-like approach scales with scope and complexity of the application. At one end is "not very complex, not very useful" and the opposite end is "many man-years to build, impossible without something like MVVM".

Testability goes hand-in-hand with this - applications small enough & simple enough that MVVM feels over-the-top are also so small and simple that real unit test coverage is farcical. However, the real world is usually very complicated, which means real-world apps do need unit tests to maintain quality and they do need MVVM to be testable and manageable. Anyone who thinks they are getting by without them are burning a huge amount of energy where very little is required; or worse, letting serious quality problems be masked by something else.