One sentence explanation to MVVM in WPF?

Question

I heard its the next best thing in building WPF UIs, but all existing examples have dozens of lines of code - can I get a Hello World for MVVM that explains in no uncertain

Answer 1

I would say something like: "Presentation pattern for separation of concern between user interface and it's logic"

Answer 2

An improved answer:

MVVM is all about the future; you want to separate your application logic from the framework so that either the framework can evolve, and your app may not have to change, or your app can evolve and you won't have to worry so much about changing the actual UI aspects.

Actually, MVVM is a refinement of a pattern that has been around for some time. I can remember evolving the pattern when I was working in MFC. There are at least two reasons for doing so. MFC or <> is fairly complex, and mixing MFC constructs in with your application logic makes the application kind of brittle. Example: replacing a listbox with a combobox (or selector in modern terms) is much more difficult if the logic for supporting the content of the list/selector is combined with the logic to manipulate list/selector itself.

Answer 3

a pattern where the frontend(view) and backend(modal) communicates (back and forth) using a common mediator(view-modal).

Answer 4

One sentence? Here goes.

MVVM is a UI segregation pattern where the Xaml (View) binds to a facade (View Model) allowing the guts of your program (Model) to avoid having UI concerns leak down a layer.

Answer 5

One sentence explanation:

MVVM is a reimagining of the well loved Model-View-Presenter (MVP) pattern that is designed to work especially well with databinding facilities supplied with WPF to separate application logic from UI design.

Longer, more useful, explanation:

The basic concept of MVVM is the break apart a WPF application into separate components each of which has one responsibility in the process of getting information on screen.

Firstly you have the model. This is a class with very limited functionality that is generally populated from some outside source such as a database or webservice. For example:

public class MessageModel
{
    public string Message { get; set; }
}

On top of that you layer the ViewModel, this is where the logic of the application sits, it notifies the view of changes to the model and ensures data consistency. By implementing the INotifyPropertyChanged interface two way databinding between the ViewModel and the view is given for free by WPF:

public class MessageViewModel : INotifyPropertyChanged
{
     private MessageModel _model;

     public string Message
     {
          get { return _model.Message; }
          set
          {
              if (_model.Message != value)
              {
                  _model.Message = value;
                  OnPropertyChanged("Message");
              }
          }
     }
}

Finally you have the View. This is a xaml file that describes the layout of the controls used to display and edit the data in the ViewModel:

<Canvas>
     <TextBox Text={"Binding Message"} />
</Canvas>

The reason that you go to all this effort is that the Model is very lightweight and easily passed across domain boundaries. It is simple to send or receive it from a webservice or map it to a database table. The ViewModel, on the other hand is complex, but has few dependencies - it doesn't care where the model gets it's data from, only that it is there and it has no concept of a view at all which makes it very testable (the logic of your application doesn't rely on a UI to test). Finally the xaml is well compartmentalised and can be handed off to a designer who needs to know nothing about the logic of the application, only that the ViewModel will present certain data under certain names. This encapsulation makes it very easy to define roles in large projects, or put together a limited UI to test logic against while the real one is being polished.