Thoughts on an MVVM Rant

I stumbled across “A vent abount MVVM Development” thanks to a tweet from @peterbromberg. Excerpt:

What really irritates me is that I am forced to waste so much time on how to try and figure out how a complex User Interface will work together with a suitable "ViewModel" all for the sake of being more "testable".  I could cobble together a pretty darn good application and still be able to split up the work among User Interface and code-behind developers.  I think adopting a non-industry standard, seemingly "best practices" ideology just because it seems 'cool' and it's "there" is the wrong approach to application development

Ah, MVVM! MVVM is the rock star who packs the house at every XAML event. It’s in books, blog posts, and podcasts. You can’t swing a dead laptop without hitting someone who is spouting about the virtues of model-view-viewmodel. With so much hype, there’s bound to be backlash.

Does MVVM deserve the hype?

Short answer – no.

An Alternative?

You’ve got a complex UI with lots of rules, and you reject the MVVM best practice crap the whiteboarding architect is jamming down your throat. You’re gonna be … pragmatic!

void SaveButton_Click(object sender, RoutedEventArgs e)
{
   if(ThisIsValid)
   {
       if (ThatIsValid)
       {
           IsDragging = false;
        
           if (DraftCheckBox.IsChecked.HasValue &&
               DraftCheckBox.IsChecked == true &&
               ItemList.SelectedItem != null)
           {
               DragDropTarget.Children.Clear();
               SaveSomethingToWebServiceAsDraft();
           }
           else
           {
               DoSomethingElse();
               EmptyAllControls();
           }
       }
   }
}

Managing a complex UI by jamming code into event handlers results in something spectacular – as does throwing a bucket of water on a raging grease fire. Afterwards the fundamental problem of complexity (or fire) still exists – and it’s even worse than before!

Doesn’t MVVM Take Care of Complexity?

I’d argue that MVVM doesn’t solve the complexity problem by itself. Neither does SOA or object databases or tomorrow's next big thing. They all help - but they don’t make complex requirements disappear. At some point you have to roll up your sleeves and work on a design that manages the complexity at an acceptable level for your team, your skill level, your business, and your environment. Experience plays a key role here because it’s all been done before. Breaking complex things into simple, composable pieces requires practice with abstraction techniques and knowing where to apply the right amount of encapsulation.

One drawback to the MVVM hype is how the hype drives people to one solution for every problem. The truth is there are lots of tricks to managing a complex UI, and some of them are dead simple and have built-in tooling support. Here is a sample:

• User controls and custom controls
• Behaviors (underutilized, IMHO)
• Triggers and visual states
• Events and event aggregators

The trick is to pick the right tool for the job. 

So What Can MVVM Do For Me?

I think MVVM does help to manage complexity and and produce maintainable code. I’ve had success with MVVM. Like every separated presentation pattern it divides the varied concerns of a user interface. You can’t dismiss the MV* type patterns as pie in the sky architecture –they’ve served the industry well for decades.

What makes MVVM different? Why is it shiny and new? I think it’s because MVVM’s raison d'être is data binding.  It’s easy to dismiss MVVM as just another UI pattern, but binding does give MVVM a slightly different flavor (a bit salty at times, but that’s just because of the static typing). If you’ve already been using a separated presentation pattern, it’s the data binding capabilities you need to understand and leverage. Data binding is quite powerful in WPF and Silverlight. You can perform amazing feats with little effort and without sacrificing encapsulation. Giving up on data binding is giving up on many of the advantages in the platform.

Proper use of MVVM also gives you a testable chunk of code. I think it’s strange that the MVVM rant dismisses the work needed to make a complex UI testable. I’d think a complex UI would need more testing than a simple UI.

On the other hand, I did just read “How a stray mouse click choked the NYSE & cost a bank $150K”, so I might not be thinking clearly.