How do you name your ViewModel classes?

Question

What kind of naming convention is appropriate for ViewModel classes?

Example: for HomeController, Index view? HomeIndexViewData doesn't seem right.

Answer 1

EmployeesViewData.

That's what I use and what I've seen in sample applications as well.

About your added example: Imho the name of the class should specify what kind of data it contains. "....IndexViewData" is rather meaningless. What exactly is displayed on that page? Try to summarize it in 1 or 2 word(s) and add 'ViewData' behind it.

Or else just take the name of the controller and drop the "index". HomeViewData sounds fine to me.

Answer 2

I prefer HomeViewModel, or using the previous employee example, CreateEmployeeViewModel, EditEmployeeViewModel, etc. The idea is that the "ViewModel" emphasises the fact that we're dealing with presentation concerns, and disambiguates the ViewModels from any domain model objects that you may have.

Answer 3

I try to keep my presentation model names agnostic of the kind of presentation they will be presented with. I may use my model object for an ASP.NET view initially, but later on I may also use it in a WCF or WinForms app. I try to name my models such that they logically describe what they contain, without muddying them up with "ViewData", "ViewModel", "Model", etc.

Examples:

ProductsWithPageInfo
ProductWithAttributesAndTags
ClientAndBillingDetail
UserAccountWithAssociatedGroups

Etc.

Answer 4

I've been using the term Envelope as part of my names, which I started using shortly before I read chapter 1 of the Wrox book and discovered the more commonly-accepted term is ViewModel.

However, these ViewEnvelopes that I create are only for very simple encapsulation when I have two or more (typically unrelated) strongly-typed models I'd like to hand to my View. They do not contain any other functionality---the envelope is intended only as delivery mechanism in this sense, whereas the term ViewModel, for me, seems less descriptive for how I'm using it, and also possibly more ambiguous as to what its real purpose is.

I might create, for example, a CustomerUpdateEnvelope class which exists solely to deliver a Customer object and an unrelated NewsTicker object, for example, to my Customer Update view.

Answer 5

I use the following pattern because it's clear and unambiguous :

• Model : Foo
• View : FooView
• ViewModel : FooViewModel