Naming conventions for MVVM?

Question

I'm struggling a little over naming classes for my MVVM application.

I have a TrainingCourse, which is called a TrainingCourseViewModel, but I can have many of these, so I have created a TrainingCourseViewManager to hold the list of courses and allow them to be added/removed. I also have an EmployeeViewController which has a reference to other view models as well as the TrainingCourseViewManager.

The EmployeeViewController essentially wraps all of the other view models and view managers and when its instantiated it gets the employee and in turn instantiates each of the view models and view managers.

The question is... What naming conventions are people using?

Should my TrainingCourseViewManager be called TrainingCoursesViewModel and should my EmployeeViewManager be called EmployeeViewModel?

Thanks

Answer 1

Should my TrainingCourseViewManager be called TrainingCoursesViewModel and should my EmployeeViewManager be called EmployeeViewModel?

What are your window classes called? (what is your .xaml file called?)

The naming convention goes, that you create one ViewModel class per View (a view is a .xaml/.xaml.cs pair)

If you have a single window which displays a list of Employees and Training Courses, then you'd have something like this:

namespace Models
{
  public class Employee : INotifyPropertyChanged { ... }
  public class TrainingCourse : INotifyPropertyChanged { ... }
}

namespace ViewModels
{
  // assuming you have TrainingWindow.xaml

  public class TrainingWindowViewModel : INotifyPropertyChanged
  {
    public ObservableCollection<TrainingCourse> TrainingCourses
    { get{ return m_trainingCourses; } }
    { set{ m_trainingCourses = value; RaisePropertyChanged("TrainingCourses"); } }

    ...
  }

  // so on and so forth
}

Answer 2

There might be a confusion over the role of view model.

Classes in your example (and in Orion's answer to that matter) seem more like actual data model. For example, it doesn't make sense for a view model to "hold the list of courses and allow them to be added/removed" - that's what data model should do. Add and remove operations on a view model wouldn't operate on the collection itself - instead, they would access and modify underlying data model.

Do properties of TrainingCourseViewModel class store actual data values, or wrap properties of some TrainingCourseDataModel class (with additional processing)? Or if you need to serialize data, would you serialize TrainingCourseViewModel objects? If former is true, you are binding directly to the data model, and there should be no 'ViewModel' suffix in names.

---

On the topic of naming conventions, if names become too complex, namespaces can help. For example:

namespace TrainingCourseView.ViewModel
{ 
class TrainingCourse {} 
class Manager {}
class Controller {}
}
...
Data.TrainingCourse course;
new ViewModel.TrainingCourse(course);