Naming Convention for ViewModel Child Objects

Question

I am building an ASP.Net MVC application using a ViewModel approach to keep my domain entities separate from the "models" used by my UI. I am using the following convention for naming my ViewModel classes. ViewModelName = ViewName + "ViewModel". For example:

Index + ViewModel = IndexViewModel

So far, so good, this is a fairly common pattern and there is a lot of guidance on this topic on StackOverflow and elsewhere. My question concerns child objects used by my ViewModels. If my ViewModel requires a class with properties identical to my a domain model object, I simply include the domain model within my ViewModel. For example:

public class PersonViewModel
{
    public int PersonID { get; set; } 
    public Address Address { get; set; }
    public string SomeOtherProperty { get; set; }
}

However, I am not sure what naming convention to use when I need a child object with different properties from my domain model. For example if Address needed a few additional properties besides what is in the Address domain model, what should I call it? I considered AddressViewModel like so:

public class PersonViewModel
{
    public int PersonID { get; set; } 
    public AddressViewModel Address { get; set; }
    public string SomeOtherProperty { get; set; }
}

but that just doesn't feel right to me. My gut instinct is that the ViewModel suffix should only be for the top level ViewModel.

I am looking for suggestions from other developers on what naming conventions they use in this scenario, specifically what would you call the child object in this case?

Answer 1

I'm going to put an answer on this just because no one else has! (I know I'm a little late to this party!)

I've pondered over this exact thing many times and tried different conventions over the years. The one thing I picked up on is that you are using a naming convention...

If your naming convention is to suffix your UI model classes with 'ViewModel' then the child models should have the same suffix otherwise you're breaking your own convention!

Also lets say you have an Address table (or whatever you have) and a Customer can have an address and a Company has an address and they both use the same table, then you may use the same child model for both parent models. It seems right to have an AddressViewModel. One day you might have a View/PartialView and it's model is IEnumerable<AddressViewModel>

I know there's no real right answer to this, but this is my answer :-)