Naming convention for child ViewModel objects

Question

I am creating an ASP.Net MVC application using the ViewModel approach so that my domain objects are separated from the “models” used by my user interface. To refer to ViewModel classes, I use the following convention. ViewModelName = ViewName + "ViewModel". For instance:

Index + ViewModel = IndexViewModel 

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

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

However, I am not sure which naming convention should be used when I need a child with different properties from my domain model. For example, if the “Address” requires several additional properties, in addition to what is in the “Address Area” model, what should I name? I considered AddressViewModel as follows:

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

but I just don't like it. My gut instinct is that the suffix ViewModel should only be for the top-level ViewModel.

I'm looking for suggestions from other developers about what naming conventions they use in this scenario, in particular, what would you call a child in this case?

Answer 1

I am going to answer this only because no one else has! (I know I'm a little late for this party!)

I thought about this many times and tried different agreements for many years. The only thing I understood is that you are using a naming convention ...

If your naming convention should suffix your user interface model classes using "ViewModel", then child models must have the same suffix, otherwise you violate your own convention!

You can also say that you have an address table (or you have one), and the Client can have an address, and the Company has an address, and they both use the same table, then you use the same child model for both parent models, It seems right to have an AddressViewModel , one day you might have a view / partial view that the IEnumerable<AddressViewModel> model

I know that there is no real correct answer to this question, but this is my answer :-)