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.
6
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.
1
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;}
...
}
0