Say I have a viewmodel like this:

public class EmployeeViewModel
    private EmployeeModel _model;

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

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.

  • If you only swap the _model, will NotifyPropertyChanged get triggered? Oct 1, 2013 at 15:30
  • @KonradMorawski Yes, should have mentioned that. Oct 1, 2013 at 15:37
  • Wouldn't a question like this belong at SO itself? I would consider moving it to SO.
    – Joe
    Nov 19, 2013 at 19:23
  • @Joe, this question is about how to correctly use the MVVM pattern, not so much about any specific implementation. Not that it matters, doesn't look like anyone wants to answer anyway :) Nov 19, 2013 at 19:26
  • I'll try answering it for you. I think MVVM is interesting :) Are you using any specific framework? I would expect the docs of the frameworks to address this though.
    – Joe
    Nov 19, 2013 at 19:34

3 Answers 3


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.


As the requirements change your view model will have to adapt to these requirements.

It might be the case that you want to display employee in multiple screens. If that's the case, then I would re-use the same view model. You may want to rename this view model to DisplayEmployeeViewModel, which is perfectly fine.

Later on you may have to create UpdateEmployeeViewModel and RemoveEmployeeViewModel.

On a side note, having a BackgroundColor in the view model might not be a good idea. Anything to do with presentation (colours, visibility, font size etc) normally lives in the view.

With regards to swapping out view models - I normally just swap out the models. For example, I have a view model that lists potential mail recipients. When recipient is selected, I store it in the SelectedRecipient property (which is a model). At no point I renew the view model.

  • The VM is conceptually part of the UI layer, so I don't see anything wrong with presentation logic there. Consider a row highlight color which varies according with some state of the model (book is overdue or not, for example).
    – Andy
    Jun 3, 2015 at 1:39

I would suggest using a generic BaseViewModel and then having subsequent ViewModels inherit from that one. In order for the BaseViewModel to work, you would have to use reflection.

public class BaseViewModel<T> : IViewModel
where T: new(), class
    // I handle most of the logic for the ViewModels and I can process
    // any model using reflection. I don't even know property names or
    // how many properties a model has, the Reflect class I refer to helps
    // me process everything

public EmployeeViewModel : BaseViewModel<EmployeeModel>
    // I have very little to do here if anything

public ManagerViewModel : BaseViewModel<ManagerModel>
    // I have a little to do so I'll add a few new methods
    // and perhaps override my parent methods 

My BaseViewModel, without knowing anything about the generic models handles much of my heavy lifting (ie SelectedRecord, CurrentRecord, AddRecord, DeleteRecord, ValidRecord). And after implementing my Reflection class, you never have to know anything about which properties are being used by the model.

In my model, it is VERY important that my property attributes contain type info, names, etc. or else my Reflect class would be useless.

It makes adding new View/ViewModels (I use the same logic for my Views) so simple and the only time I have to add properties and methods to my child view model is when it behaves differently than the rest.

Everything is dynamic. The only time I have to refer to properties in my Model, like in your example, is when Im designing my model. Once I've created my model, creating my views and viewmodels are simple. Sample model

public EmployeeModel: BaseModel 
    [Column(Title = "#", Field = "employee_id"...)] 
    public ID{ get; set;} 

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.