MVVM – Model View ViewModel

That’s kinda weird acronym. And if you want to be very famous, you can use very catchy phases like

“Im going to do MVVM in a SLOOB with SLUT”

And there are some confusions around MVVM. Let me clarify things first,

• MVVM is nothing but a Pattern. Its in WPF or SL tho you dont use it. For instance, the controllers you use are built with mini MVVM.
• Also known as Presentational Model.
• The rest of this things are Helpers, Practices etc.

Lets see some variations of similar patterns;

MVC Pattern

Model View Controller is probably the oldest pattern. May be since 1980s. This is still use widely, especially with ASP.NET MVC.

Passive View Pattern

This is a variation of MVC pattern. The advantage that we see here is that the View is completely Passive. The controller has lot of responsibilities. Since the View is not reacting to anything you don’t need to test it. For me, that's a relief, coz, testing a View is very difficult and time consuming.

Presentation Model Pattern

Another variation of Passive View Pattern is the Presentation Model. Here the Controller is replaced by Presentation Model and we can call this as a ViewModel.

Here the View is more active and pushing information to the Model. OK, so before this, we saw the goodness about the View being completely Passive. So the trick here is that the interactions is done via Data Binding.

When you have a Framework with Data Binding, for instance, WPF and SL, you really dont need to worry about View being active. This is built in the framework so you dont have to test it, coz Microsoft did that for you.

So, what have we learned so far? Yes, Model, View, ViewModel and Bindings. Its not that complicated and thats MVVM, everything else, is Helpers around MVVM.

Lets talk about a bit on the helpers. They are nothing but Commands, and Messages. Its got nothing to do with MVVM. You can straight away use without MVVM Pattern.

Sometimes View might need to notify the ViewModel about something happened in the View, for example; a control being clicked. Its a good job for Commands.

1 ways is that we can use very basic Command Pattern implemented with ICommand interface. What I see as annoying is that I have too much code here. I have to have separate classes for each Command and pass in the ViewModel.

What breaks you application is code. So another way is to minimize the code and to get rid of these annoying Classes is to use the RelayCommand (sometimes it is called Delegate Command Pattern) Component inside your ViewModel.

The other directions is also good for sometimes, when a ViewModel can notify to the View when something happen. 1 way is to use Events, another good way is to use Messages. This is good, coz most of the time we end up with multiple ViewModels.

To notify the View, we can simply use Events. But with WPF and SL, we can get the advantage of Messenger Component and we can simple get rid of all the Events and Delegates.

You can express all your MVVM Feelings with the use of MVVM Light Tools V3. This is an open source MVVM very light Framework with 2 DLLs. It contains essentials such as RelayCommand, Messenger, and ViewModelBase components. Some extras such as EventToCommand which can be used to get rid of annoying WPF and SL Command binding limitations, and DispatcherHelper for multi-threaded applications.

Cons in MVVM

You have to write lot of code in MVVM.

• You have to implement INotifyPropertyChanged interface on your ViewModel. You cannot use Automatic Properties. You have to expand my properties.
• You can only use Command with limited controls basically Clickable controls. You cannot use this with any event you want.

Some operations such as Setting Focus on a UI element from the ViewModel coz the ViewModel doesnt know the View. We can use the code behind for these kinda operations.

You cannot use this pattern in other platforms such as ASP.NET etc. coz its highly use Bindings. You might be able to use this pattern in ASP.NET MVC but it will be a different kinda implementation than what we have in mind.

There are lotsa toolkits and frameworks which sometimes confuses since there are no formal guidance. Not even from Microsoft YET!

Some Myths about MVVM

“No code in the code behind.”

“If you have code in your View’s code behind, MVVM Police is going to take your family away.”

There is something called “Code Behind For a Reason”. But what I see the problems is that it is not that easy to test your Views if there are code in your code behind.

“No need for Converters.”

Sometimes you might need to use Converters, but I would say it is LESS use in MVVM.

“MVVM is only suitable for BIG projects.”

It is suitable in lot of cases that we can gain advantages of Data Binding.

“MVVM Costs Performance.”

Well, I would say Developer Performance since it requires some skills to understand the Patter and you have to do some additional coding such as Commands etc. But I think the Data Bindings are very optimized. You mileage may vary.

“MVVM is complex. Makes my head hurt”

Well, its nothing but a Pattern. The rest of the stuff are helpers and if your head hurts, it probably becoz of Last Night :)

“I dont need separation coz I dont have a designer.”

I think separation is about maintainability, and testability other than blend-ability.

“You cannot use MVVM with other patterns.”

Well, Why Not. You can use in a User Control with MVVM, and use this User Control in any other places.

“MVVM will make you rich and attractive.”

 

Stolen from Laurent Bugnion’s presentation, Understanding the MVVM Pattern.

More Information can be found on;

Codeplex, MVVM Light Toolkit
http://mvvmlight.codeplex.com/

Galasoft, Understanding the MVVM Light Application Sample
http://www.galasoft.ch/mvvm/sample1/index.html

Galasoft, Creating a new MVVM Light Application in Visual Studio
http://www.galasoft.ch/mvvm/creating/

MSDN Blog, Dan Crevier’s Blog MVVM Series
http://blogs.msdn.com/dancre/archive/tags/DM-V-VM/default.aspx