MVVM Unique Benefits

Question

A stackoverflow search will result in several postings that contain similar titles, but this is different question. Since this is not a discussion site, I have to ask a different question.

What unique benefits do I get from using MVVM that I can not get from any other implementations? MVC. NTiers, or anything else. Im not really looking for the identifying features that make MVVM different. Im looking for the things that can not be done in anything else but MVVM. My current knowledge on it leads me to think, that MVVM is different way to do the same thing that introduces more complexity then say nTiers. I dont want to take the angle that the introduction of this complexity , is a negative thing. If it is justified by the enabling of unique benefits then I would like to know this.

An in depth google, has only turned up MVVM defenitions. It has not turned up these unique benefits.

Answer 1

The only benefit that I can think of that is specific to the MVVM pattern over MVP (of which it is a variant) is that in MVVM, you do not need to explicitly attach a View to a ViewModel (Presenter) as you would in an MVP implementation. This is enabled by the facilities provided by WPF. (BindingExpressions most importantly) In MVP, you would define an interface that represents how the presenter can interact with the view (IxxxxView is a conventional naming pattern) and when you create your presenter, you pass in the view interface to it (which is attached to the view instance). This does allow for some view variations on top of a common presenter as well.

In MVVM, you don't explicitly define that interface. You define your ViewModel and use Binding to hook a ViewModel (logic) to a View (presentation). There is no intrinsic knowledge of the ViewModel in the View as the bindings (if they are done in XAML) are resolved at run-time (or sometimes in the designer). In theory, a WPF application should be able to be driven completely without a UI.

The benefit that you get from MVVM/MVP/MVC is primarily the separation of concerns between presentation and business logic and what this allows. It allows for specifically skilled roles (read: actual graphic designers) to work on presentation without having to know anything about C#/VB.NET code. They can build the presentation, and the developers will come along and hook things up afterwards.

Also, the developers now have patterns that allows for the automation of testing of the code via unit tests. Because the applications can be driven (mostly) without a UI, unit tests are a great tool for allowing developers to really exercise all of the code they write.

This doesn't really address a comparison between "N-Tier" and MVVM though because I don't know that that is an apples to apples comparison. Arguably, MVVM WPF applications are N-tier applications, with several logical layers in the solution.

Ultimately, MVVM/MVP/MVC are all very comparable patterns, with the same sorts of benefits. One thing though, is though is that MVVM as I know it can only be used when WPF/Silverlight is the presentation technology of choice. And I guess that is a singular benefit of MVVM. It is specific, and the optimal pattern, for us in WPF/Silverlight. After using MVVM, it would feel clunky to use any other pattern in WPF.

Answer 2

MVVM is just a tiny twist on a the class "Model-View-Presenter" pattern. The only diff with MVVM is that your 'view-model' classes are designed specifically to play nicely with the databinding features that are built in to WPF and Silverlight in order to minimize the need for any code in the View itself (keeping the View purely XAML markup that can be edited/replaced in a designer). If you are using WPF or Silverlight, it's definitely worth a close look. If you are using anything else, it's not really applicable.