WPF/MVVM - should we create a different Class for each ViewModel ?

Question

I'm attempting the example from the excellent "How Do I" video for MVVM by Todd Miranda found in MSDN.

I'm trying to adapt the example for my learning purpose.

1. In the example, he has a ViewModel called EmployeeListViewModel. Now if I want to include Departments, should I create another ViewModel such as DepartmentListViewModel?

2. The example has EmployeeRepository as the Data Source. In my case, I'm trying to use an Entity object as the datasource (Employees.edmx in Model folder and EmployeeRepository.cs in DataAccess folder). If I want to display the list of Departments, should I create a separate class called DepartmentRepository and put all department related method definitions there?

3. What if I want to retrieve the employee name and their department's name together? Where should I place the methods for this?

I'm very new to WPF and MVVM and please let me know if any of the above needs to be re-phrased.

Thank you for all the help.

Answer 1

Yes, generally each View (Page, Window, Screen) should have it's own ViewModel. So, if you want to have a screen that lists some employees, your ViewModel would have some kind of collection of employees (IEnumerable) as a property. Your employee type would then contain properties for their name, department, phone extension (etc).

I'm not exactly clear from your question whether you want to display the list of employees and departments on the same page. If that is what you are trying to do, then you'd have two properties in your ViewModel that are some kind of collections like this:

public class EmployeeListViewModel {
     public IEnumerable<Employee> Employees { get; set; }
     public IEnumerable<Department> Departments { get; set; }
}

...which would allow you to display both collections on your view.

Answer 2

It depends, as every pattern is more like and idea/concept than something you need to follow strictly. By saying this you will notice that sometimes yes, is advisable to use a class for each ViewModel or maybe use a generic ViewModel if applies. I know it's hard because I was (and still I am) in the same position as yours.

In question 2, What I do sometimes is to Retrieve and IQueryable and then "translate" the returning object to a ViewModel. Repositories/Domain should not know nothing about ViewModels, since is just a presentation thing.

Answering point 3, if you need to bind a control with Employee and Departments together, Maybe you can do something like this:

public class EmployeeDepartmentsViewModel : BaseViewModel //Base View Model has INPC stuff
{
    public Employee Employee { get; set; }
    public Department Department { get; set; }
}

Hope this clarifies your doubts.

Answer 3

There are no hard and fast rules here. I'll address each concern individually:

1. You would have one ViewModel for each unique View you had. I think that calling it [Entity]ListViewModel might have confused the issue. Name it the name of the view... if you are looking at the DepartmentDashboard, call it the DepartmentDashboardViewModel.
2. For your model, there are no rules and there certainly doesn't have to be a 1:1:1 ratio of model objects to view models to views. Generally I have one OR/M setup when dealing directly with a database (like TheBigDatabase.edmx) and this happens to be made up of many models (Employees, Departments, Accounts, Transactions, etc). Do whatever feels good here.
3. Since you are going to create an edmx with multiple entities (as I suggested in #2) in it, you will be able to take advantage of the relationships between these entities (Employees have Departments, I would guess, so Employee.Department would be there). Once you have this, you can display the related data all in one place if you wish.