OdeToCode IC Logo

Thoughts on an MVVM Rant

Tuesday, February 2, 2010

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

MVVM Rockstar 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 (ThatIsValid)
           IsDragging = false;
           if (DraftCheckBox.IsChecked.HasValue &&
               DraftCheckBox.IsChecked == true &&
               ItemList.SelectedItem != null)

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.

Gravatar Mike Tuesday, February 2, 2010
I just arrived on a project where there are multiple button-click event handlers with 3000+ lines of code. Extracting the business logic from those methods is not the best use of anyone's time.
Gravatar Scott Allen Tuesday, February 2, 2010
@Mike: Ugh.
Gravatar Chris Nicola Tuesday, February 2, 2010
The MVVM pattern will often get taken to the point of anti-pattern. I would say if your VM starts looking like your old code-behind you've hit that point.

My typical approach to WPF/SL development patterns:

- View Model: View data for binding (little else, minimal behavior, if any)
- Controller: Behavior and co-ordination between components
- Event Aggregator/Events: Communicates between components, response to actions, notifications, triggers
- Command: Binding user actions to the ViewModel, usually triggering an event, or some behavior directly on the controller

It is an evolving concept though and it rarely starts out this way. Often I start with just Views and ViewModels that have and do everything (code-behind anti-pattern) and then refactor out the complexity.
Junt Tuesday, February 2, 2010
I am working on a project using MVVM. I must say it is pretty good by leverage the data binding and command capability of WPF/Silverlight to achieve the SoC principle.
MVVM does deserve a great attention from all WPF/Silverlight developers.
But we do have fights in the team that some old folks just do not get the idea of MVVM.
Junt Tuesday, February 2, 2010
I am working on a project using MVVM. I must say it is pretty good by leverage the data binding and command capability of WPF/Silverlight to achieve the SoC principle.
MVVM does deserve a great attention from all WPF/Silverlight developers.
But we do have fights in the team that some old folks just do not get the idea of MVVM.
Gravatar Muffadal Wednesday, February 3, 2010
Hi Scott,

You said "The trick is to pick the right tool for the job."

Could point out in which case you would use what tool or may be some previous article or blog post in that direction.

Gravatar Shiju Varghese Wednesday, February 3, 2010
Hi Scott,
Great post.
Joseph Cooney Wednesday, February 3, 2010
The phrase "adopting a non-industry standard" from the rant struck me as odd. What is the "industry standard" then? To my mind MVVM is just another name for the Presentation Model pattern catalogued by Martin Fowler, which is part of a family of patterns which include MVP, MVC etc. which are "well regarded" to say the least. If these aren't collectively the "industry standard" for presentation framework architecture then what is?

I like and use MVVM - and as you clearly point out the "secret sauce" is data binding. My mental model when desiging a ViewModel is "what would the perfect object for my screen to data-bind to look like?"
Gravatar J.P. Hamilton Wednesday, February 3, 2010
I don't have a preference for MVVM or MVP. The pattern has to have reason for its use. It's all about testing for me. If you can test your code in that click event then more power to you. If not, that is an indicator you need to try something else.
Gravatar SarahBh Saturday, February 6, 2010
If make a choice to perform the custom research paper, you would have to remember that it demands a lot of time! Some students flush their written paper, just because they do not have writing skills! That’s bitter, but the buy essay papers service would assist such kind of people any time.
Gravatar Matt Briggs Monday, March 1, 2010
My question with MVVM is that why are we adding another data translation layer just for data binding? Does the benefit outweigh the cost? And if it does, how long will it be until we have OR/Ms specifically designed for WPF to handle the additional complexity in working with the framework?

What is wrong with having a view consume multiple models? Or having view related logic in a view logic class that is not a model?
owen Thursday, April 15, 2010
I've just started looking in to MVVM and as far as I see it, the time saved in testing is WASTED wiring up objects in a fancy web of random meaningless api calls in camel toeText.

It seems to be more an API than a real language supported pattern. There is too much magic going on and not enough steam engine.
Gravatar Henry The Hogg Monday, August 9, 2010
public class ViewModel<TCommands, TdmProvider, TDataModel, TModel, Tid>
where TCommands : ICommands<TdmProvider, TModel, Tid>
where TdmProvider : IDataModelProvider<TDataModel, TModel, Tid>
where TDataModel : IDataModel<TModel, Tid>
ViewModel(TDataModelProvider provider)
Commands = new Command { Provider = provider }

public TCommands Commands{ get; set; }

public TDataModel DataModel {get; set; }
Henry The Hogg Monday, August 9, 2010
My conceptual view of the MVVM architecture.

The data model represents the VM for the model, validation and property changes.

The Commands are the command view model containing 1 or more commands.

The data model provider builds data models.
Gravatar merchantcash Monday, September 13, 2010
Really your blog have nice post so I became the permanent visitor of your blog.
SpeakingStones Monday, October 25, 2010
MVVM is a beast of a pattern. It leverages XAML which is the worst parts of WPF/SL. Complex apps become nearly impossible to debug, especially if you are lumped with another developers code. XAML itself is a complete dogs breakfast. Untyped code in xml??Come on people open your eyes, you have all been lead down the garden path on this one!
Gravatar mde Friday, January 7, 2011
You may be interested by some return on experience around MVVM and testability.

Comments are closed.