MVC Framework ViewModel naming conventions

There are many ways of naming & organising your View Models in a MVC application. This post describes some easily followed conventions for this.

Organising the View's Models

First we need to decide where to store the models. MVC conventions have Controllers in one directory and Views belonging to the Controller in a Views sub-directory with the same name as the Controller.

For example, for the HomeController we will expect to find its Views in /Views/Home or /Views/Shared directories.

So it makes sense to use a similar convention for models used by Views (I'm deliberately not going to call everything a "View Model", which I'll explain shortly).

A default MVC installation includes a Models directory, so using a similar convention to Views, we can create a separate directory for each Controller under the Models directory.

In this case models used by the HomeController will be found in /Models/Home or /Models/Shared. So now the directory a model is in makes it clear which Controller it is used by.

Naming Convention for View Models

When a Controller is preparing the data for a View, this data is typically encapsulated in a View Model. For example:

public ActionResult Index()
{
  var projects = _projectsRepository.GetAll();

  var viewModel = new IndexViewModel
          {
            Projects = projects,
            Date = DateTime.Now
          };
  return View(viewModel);
}

View Model Class Name

The convention is:

[ActionName] + [ViewModel] 

Example: Index + ViewModel = IndexViewModel

View Model Variable Name

I'm all for keeping things simple, and like to use the same variable name wherever a View Model is being referred to:

var viewModel = ...

The big advantages of these naming conventions is that it is quick to choose a name and obvious from the name & structure where the model is being used.  It does have the drawback that there is less semantic meaning than a carefully crafted ViewModel name, like currentprojectsforreviewmodel

I have seen others naming the ViewModel after the View it is for. This makes some sense, but where Views themselves call other Partial Views, this convention breaks down.

Other Model Naming Conventions

The ViewModel naming convention described above works well when sending data to a View, and also for receiving data from a View if the same model is just being round-tripped.

But it isn't so clear when a request is coming in from a page that didn't start life as a ViewModel, or data has to be sent out from a Controller to something other than a View (for example a JSON request).

For these scenarios we use slightly different naming conventions.

RequestModel and ResponseModel

Where the Controller action is being used more like a service, perhaps to receive & send JSON data, it doesn't make as much sense to use the name "ViewModel".

In these scenarios we just use the same conventions as above, except using the term "RequestModel" for in-bound data and "ResponseModel" for out-bound data, instead of "ViewModel":

[HttpPost]
public ActionResult Add(AddRequestModel requestModel)
{
  foreach (var task in requestModel.Tasks)
  {
     // Do something
  }
  // Prepare response
  var responseModel = new AddResponseModel{...};

  return Json(responseModel);
}

That's Not All Folks

These conventions are a good start, but don't cover all scenarios. For example, if your ViewModel itself contains child objects, what naming convention should you use for those?