When do we use MVVM?

Question

I have been hearing a lot of hype about MVVM for WPF.
When do we use it?
Is it a use for everything or does it only have specific uses?
Is it worth it for every project?

Answer 1

I've found it useful even in relatively small projects, if I'm making a lot of use of databinding and an object data model / models.

Answer 2

In terms of WPF and Silverlight?

In theory for everything - every non-trivial project (and possibly even then). Its part of a wider process (it creates separation of concerns and allows for testing and other nice things). Basically if you're going to do it (and I think you probably want to, I certainly intend to with new projects) then you should do it pretty much across the board.

If you haven't already, go watch the video linked from here: http://blog.lab49.com/archives/2650 - I found it very helpful in getting my ideas straight.

Answer 3

It can be useful in any project, but I find it particularly helpful in situations where providing a clear separation between business logic, interaction logic, and user interface is required (large applications or applications involving multiple developers/designers).

Model = Business Logic

• Contains the model of whatever business process/object I am working with.

ViewModel = Interaction Logic

• All the code that controls how the model is accessed and modified (e.g. edit/undo functionality, lazy loading, etc.)

View = User Interface

• The interface (defined in XAML) that the user interacts with. I try to minimize the use of code-behind in this layer, pushing that into Attached Properties or the ViewModel.

There are doubtless many other uses for MVVM, but this particular scenario is the one I have found to be the most useful in my own WPF development experience.

Answer 4

Better to ask: when shouldn't you use it? The most obvious example is when data binding isn't appropriate and you have to manipulate elements of the view directly in code - if, for instance, your application needs to update the visual state of hundreds or thousands of visual elements in real time you may not be able to afford the overhead of data binding.

Answer 5

I'm currently working on a large project, where we implement mvvm, CAL (Composite application guidance) in Silverlight. Of course, level of separation of concerns is very high.. but

1) the code gets too robust.

2) MVVM looks great for small projects ( all these hello-world samples all over the internet), but it reduces your oppportunities: For example, Routed events (great instrument) are still EVENTS, but, as you know, it's strictly forbidden to use them directly, as soon as this is code-behind) if you want to follow mvvm.

3) Command Binding STILL doesn work properly in Silverlight(.net4.0, vs2010). It's a long story, just keep that surprise in mind, when your CanExecute delegate will not fire at app start.

The main part of idea of Separation of Conserns is 'Model doesnt know about view', NOT 'View cannot access the model'.

A good answer to your question is "MVVM is good for projects with simple UI logic".

Thanks, Ilya.

Answer 6

Every time I start on a simple project and think "this is so simple, MVVM would be overkill", approximately 8 hours later I get to a point where I realise that using MVVM would make things much simpler.

So I'd say most of the time using MVVM will actually simplify your UI logic, even if you initially think it will be overkill. Projects have a habit of getting more complex over time, and the separation of business logic and view logic enforced by MVVM enables the project to grow in a far more controlled way than having you business and UI logic all mixed in together.