4 Comments
  •   Posted in: 
  • MVC
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 ModelsNamingConventions

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?

Comments

Comment by Louise Eggleton

Good article, I have been using this convention and it serves me well, however I am curious what naming convention you use for child objects of ViewModels, especially child objects that don't exist in the domain model?

Louise Eggleton
Comment by Steve Moss

Hi Louise. It doesn't happen that often, so I've no fixed guidelines. Although if the view model is complex enough to need child objects it might be a sign the view needs to be broken up into multiple partial views, each with their own controller action and view model.

Steve Moss
Comment by Louise Eggleton

I stumbled upon this post again a year later and one comment I will make is that I do often break views into multiple partial views, but that is not always an option depending, on the layout of your view. Partial views only work if all the data from the model for the partial view can be displayed in a modular fashion at a specific place in the main view. If however you have data from multiple models that is "co-mingled", for exmaple in a table, then partial views will not work. In this case I tend to use ViewModels comprised of multiple child ViewModels. As for what naming convention I use for child ViewModels, they also use the ViewModel suffix, but rather than an ActionName prefix, the prefix is derived from the model name that the veiw model is derived from.

Louise Eggleton