Why MVVM and what are it's core benefits?

Question

Why we go for MVVM over MVC or MVP while dealing with WPF?

What extra benefit we get by using this?

Edit:

To be honest , today I had an interview and I have been asked this question. I answered like INotifyPropertyChanged , ICommand,IValue Convertor.. but he was not satisfied. Henceforth I have put up this question

Thanks in advance

Answer 1

Baked in support for ICommand and INotifyPropertyChanged are the two biggest benefits. Using MVVM makes it really easy to wire up the commands and plug data into the WPF UI. Things just work.

Answer 2

WPF has better databinding than any other UI framework, which MVVM would be unruly without

MVVM provides unit testability and excellent view-agnosticism, which make it a good thing to use

Answer 3

These are mine specific to MVVM

1. Increases the "Blendability" of your views (ability to use Expression Blend to design views). This enables a separation of responsibilities on teams that are lucky enough to have a designer and a programmer... each can work independent of the other.
2. "Lookless" view logic. Views are agnostic from the code that runs behind them, enabling the same view logic to be reused across multiple views or have a view easily retooled or replaced. Seperates concerns between "behavior" and "style".
3. No duplicated code to update views. In code-behind you will see a lot of calls to "myLabel.Text = newValue" sprinkled everywhere. With MVVM you can be assured the view is updated appropriately just by setting the underlying property and all view side-effects thereof.
4. Testability. Since your logic is completely agnostic of your view (no "myLabel.Text" references), unit testing is made easy. You can test the behavior of a ViewModel without involving its view. This also enabled test-driven development of view behavior, which is almost impossible using code-behind.

The other two patterns are really sort of separate in terms of the concerns they address. You can use MVVM with MVP and MVC (most good samples out there do some form of this).

In fact, MVP (w/ a Passive View, rather than a Supervising Controller) is really just a variant of MVVM, in my opinion.

Answer 4

I'll point you to a particularly useful video by Jason Dolinger.

Coming from a winforms world, implementing any MVX style pattern seemed like more hassle than it was worth but after working with WPF for a couple of years now, I can honestly say that I wouldn't consider anything less. The whole paradigm is supported out-of-the-box.

First off, the key benefit is enabling true separation between the 'View' and 'Model'. What that means in real terms is that if/when your model needs to change, it can without the view needing to and vice-versa.

Secondly, while your 'model' may contain all the data you might need in your 'view', you may want to abstract that data in such a way that your 'model' doesn't support. For example, say your model contains a date property. In the model it can exist solely as a DateTime object but your view might want to present it in a completely different way. Without the 'viewmodel' you'd either have to duplicate the property in the 'model' to support the view or modify the property which could seriously obfuscate the 'model'.

You can also use a 'viewmodel' to aggregate parts of your model that exist in separate classes/libraries to facilitate a more fluent interface for the 'view' to deal with. It's very unlikely that you'll want to work with data in your code in the same way that a user will want to or will want that data presented to them.

On top of that, you get support for automatic two-way databinding between the 'view' and 'viewmodel'.

There really is a whole bunch of extra stuff that i could bang on about but Jason say's it far better that i could so my advice is watch the video. After a few days of working like this, you'll wonder how you ever got by without it.

Good luck.

Answer 5

The ability of XAML code to databind, as well as the existance of triggers will break the MVP and MVC Patterns.