Question

I trying to understand Model to ViewModel relation and I keep bumping in the same problem.
Assuming we have a “Person” class with just one field:

public class Person
{
   public string Name;
}

In the next phase I have my XAML artist who created a user control that present a Person and he according to practice of MVVM need to relate his view to VMPerson (View-Model Person), so now I add another class:

public class VMPerson : INotifyPropertyChange
{
   private Person person;

   public VMPerson():this(new Person()){}

   public VMPerson(Person person)
   {
      this.person = person;
   }

   public Name
   { get { return person.name; }
   { set { person.name = value; PropertyChange("Name"); }
}

So now I have almost everything setup.. but how would my VM class relate to changes in my model class?? if I add INotifyPropertyChanged and add a property for “Name” in the model I endup with something very similar to my ViewModel class an extra layer which I will not need. Is there any way to keep my Model class as it is and still be notified on changes inside it in the view-model class? if there is no other way than using INotifyPropertyChanged mechanism or anything similar which will be implemented in the model why do I need VM ?? is it just for a situation that aggregate few “model” classes into one class which will be served to the View?

I think I must be missing something in my understanding cause it seems to me according to what I described that a Model to View pattern while using the View code-behind as a controller would be better abstraction than MVVM, but I certainly not sure about that.
Can someone explain to me what I am missing? thanks.

Answer 1

Putting the viewmodel code into the model is not the best idea

It’s true that viewmodels in many cases begin life by looking like extra layers of code that don’t really add anything of value, but the point is that they can evolve.

The role of a VM is to provide convenience to views — INotifyPropertyChanged is one such convenience while the role of a model is to encapsulate your business logic. As the functionality of your code grows the will keep getting richer; at some point, it might even end up being much larger in code size than your model. So the distinction is made in order that the convenience and the business logic parts are kept nicely separated from each other, which has a good effect on the maintainability of your code.

Putting the viewmodel code into the view is not the best idea

The reason here is different: if you do this and then need to use the viewmodel with another type of view, you will have to duplicate all the logic into the other view’s codebehind as well. Duplication is bad; DRY is good.

Considering that a very important feature of MVVM is that it affords testability and that testability necessarily means at least two types of views (the real one and the mock), the necessity of this approach becomes evident.