Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

One sentence explanation to MVVM in WPF?

People also ask

What is WPF in MVVM?

MVVM is a way of creating client applications that leverages core features of the WPF platform, allows for simple unit testing of application functionality, and helps developers and designers work together with less technical difficulties.

What is MVVM explain in detail?

MVVM stands for Model, View, ViewModel. Model: This holds the data of the application. It cannot directly talk to the View. Generally, it's recommended to expose the data to the ViewModel through Observables. View: It represents the UI of the application devoid of any Application Logic.

What is the purpose of MVVM?

The Model-View-ViewModel (MVVM) pattern helps to cleanly separate the business and presentation logic of an application from its user interface (UI).


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.


MVVM is a star-fan relationship. The fan knows the star but the star does not know the fan. The fan loves his star so much that if the star changes himself ( I mean his dressing style ), the fan changes himself accordingly.

Now replace "star" with "ViewModel" and "fan" with "View" and read it once again.


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.


The simple statement that helped me get my head around it best was "Could I unit test my business logic without the user interface?" I think this should be the question you ask while learning and designing using MVVM concepts.