Is MVVM really useful?

Question

I have read the MSDN article on MVVM and I am not really convinced. If the model already implements INotifyPropertyChanged/INotifyCollectionChanged, what's wrong with the View binding directly against the Model? It seems the extra ModelView introduces some code without much benefit. Am I missing something?

Answer 1

INotifyPropertyChanged and INotifyCollectionChanged are not the only aspects to be considered... In many cases, the data exposed by the model will not be easily usable by the view. The role of the ViewModel is to act as an adapter between the model and the view : expose the data in a form that allows the view to easily bind to it, expose commands to which the view can bind in order to perform actions... Typically, a model won't expose ICommands : if it does, then the model is WPF-specific, which is never a good thing is you want to reuse in some other non-WPF application...

I have been using MVVM for a few months, and it made my life much easier : no more "spaghetti code" in code-behind files, clear separation of responsibilities, clean overall architecture...

Answer 2

I was also a bit skeptical about MVVM until I watched this great presentation by Jason Dolinger. I recommend all my co-workers who are starting out in WPF and MVVM to watch it.

Jason started with an application that one would write in a “traditional” way, with button clicks handled by event-handlers in the code-behind that then updated other parts of the UI. Using WPF data-binding, Commands, and Unity, he transformed it, piece by piece, in a much more manageable, encapsulated, readable, and testable M-V-VM design. It was awesome.

To answer your question more directly, even if it seems silly to bind to a ViewModel when your Model already has everything, you'll often wind up needing one little adjustment to the Model that's needed only by the View. Over time, these little changes will creep into your Models, where they don't belong. It'll make your models more complicated than they ought to be.

What I often do when I have a Model that "has it all", is I add a ViewModel that contains one property, the Model. Then in my bindings I just bind to Model.Name, Model.Age, etc. It's really no effort. Later on, if I need tweaks only for the View, I already have my ViewModel class ready. This also makes your code more intuitive and easier to understand. You won't wonder, did I bind to the Model or the ViewModel in this case? It will always be the ViewModel.

Answer 3

I have been using MVVM for 2 projects and here are a few things that I have been doing in the ViewModel:

• Transforming the data from the model (When you are using a ViewModel, it makes life easier when UI specifications change, you don't need to change the Model/Persistence code)
• Implementing a ICollectionView over a collection provided by the model
• Implementing Commands
• Caching (maintain expensive to calculate data)
• Maintaining a dictionary on model data (for fast lookup)
• Lazy-loading (not load until it's been used by the View)
• Managing Undo/Redo
• Validation of data (IDataErrorInfo)

and there is much more to do there (that I forgot) that would not fit in the Model itself, or would make the user interface spaghetti.

Not to forget, the ViewModel enable you to unit test things that you would not be able to test if it was implemented in the UI (such as Commands).

Finally, using MVVM, I was able to build a command-line version of my application very easily by using the ViewModels.