When using MVVM, should you create new viewmodels, or swap out the models

mvvm

Say I have a viewmodel like this:

public class EmployeeViewModel
{
    private EmployeeModel _model;

    public Color BackgroundColor { get; set; }
    public Name
    {
        get { return _model.Name; }
        set
        {
            _model.Name = value;
            NotifyPropertyChanged(Name);
        }
    }
}

So this viewmodel binds to a view that displays an employee. The thing to think about is, does this viewmodel represent an employee, or a "displayable" employee. The viewmodel contains some things that are view specific, for instance the background color. There can be many employees, but only one employee view.

With this in mind, when changing the displayed employee, does it make sense to create a new EmployeeViewModel and rebind to the view, or simply swap out the EmployeeModel. Is the distinction even important, or is it a matter of style?

I've always leaned toward creating new viewmodels, but I am working on a project where the viewmodels are created once and the models are swapped out. I'm not sure how I feel about this, though it seems to work fine.

Best Answer

I think the question revolves around whether you are creating a new view or not.

If you have say multiple tabs, each one has an employeeView and corresponding viewmodel. when you open a new tab you instantiate a new view and viewmodel

If you have a single page, with 'next/prev employee' buttons then you probably have a single view and should stick with a single view model and change its properties.

If you switch out a viewmodel from a view you potentially muck up the bindings between the two. eg NotifyPropertyChanged as @konrad mentions

I've seen apps which create a new view each time which kind of works where you have a navigation controller or similar. But the more modern approach seems to be to have a single viewmodel tree for the app where its properties change overtime.

The multiple view approach can suffer from memory problems if you lose track of your views as you navigate around. Also if you are binding to a mediator or some other global events object you can find you are firing events on all your views when really you just want the active one to be triggered.

Related Solutions

MVVM Application – Who Should Control Navigation?

Navigation should always be handled in the ViewModel.

You're on the right track with thinking that the perfect implementation of the MVVM design pattern would mean you could run your application entirely without Views, and you can't do that if your Views control your Navigation.

I usually have an ApplicationViewModel, or ShellViewModel, which handles the overall state of my application. This includes the CurrentPage (which is a ViewModel) and the code for handling ChangePageEvents. (It's often also used for other application-wide objects such as the CurrentUser, or ErrorMessages too)

So if any ViewModel, anywhere, broadcasts a ChangePageEvent(new SomePageViewModel), the ShellViewModel will pickup that message and switch the CurrentPage to whatever page was specified in the message.

I actually wrote a blog post about Navigation with MVVM if you're interested

Design – How to do to create the ViewModel part of your MVVM designs

The ViewModel is an abstraction of the View.

That means you need to know first what you want to diplay to the user. At least you should have a detailled sketch of what the UI will look like (There are many tools intended to do this: MS Expression Blend, Balsamiq, etc.). Or even a dummy UI without logic plugged behind, created with your development tool.

Once you have your view, the ViewModel will be the place to hold every binded value, and what could be called display logic, mainly formatting. A View Model can be a representation of one Model, a group of Models of the same type, or an aggregation of different models.

A simple exemple of View Model is the editing screen with a drop down list. Let's have a concrete example with a User that can be linked to a division :

public class UserModel 
{ 
   public string Username { get; set; } 
   public string EmailAddress { get; set; } 
   public int DivisionId { get; set; } 
} 

public class DivisionModel 
{ 
   public int DivisionId { get; set; } 
   public string DivisionName { get; set; } 
}

It wouldn't make sense to plug an IEnumerable of divisions in UserModel, so we create a View Model to represent a displayable User, with all the data needed to have a working screen where I can select a Division for that User :

public class UserViewModel 
{ 
   public UserModel User { get; set; } 
   public IEnumerable<DivisionModel> Divisions {get; set;} 
}

And that's it. Depending on the language I'll be using, I'll just have to feed a drop down list with the IEnumerable of DivisionModels and make it show the Name member.

Best Answer

Related Solutions

MVVM Application – Who Should Control Navigation?

Design – How to do to create the ViewModel part of your MVVM designs

Related Topic