Wpf – Naming conventions for MVVM


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?


Best Solution

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);
Related Question