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?

Landrum

My personal approach is different. I don't name ViewModels based on the View name, I actually name them based on the Models they represent. However for your specific approach I would name the Address with Address also. – Equivalence

personally, i don't use a suffix, i create a new folder for my view models. If my domain entities are in a different dll, then i use the models folder and create my ui entities in there instead. I also make the viewmodels responsible for converting themselves back into domain entities by implicit operator overloading to take the heavy lifting out of the controller. – Jessjessa

@shaftpolls, would that not cause naming collisions if both the domain model Address and viewmodel Address are used both in the same file. eg both are in the same controller. I suppose I could fully qualify each variation of Address with the full namespace but that would be a PITA. As you suggested, however, I am leaning towards the idea to use the same naming convention for child objects in viewmodels as I am in my domain models. – Landrum

I believe you wont have issues of that kind, since when you reference the viewModel Address you will reference first the ViewModel itself. e.g personViewModel.Address. If my first comment was useful I will put it as an answer if you agree. – Equivalence

@shaftpolls I wasn't talking about the property name, but the class. If I have already used Address as a class in my domain model then there can be collisions if I also use Address to name a class that is a child object of a viewmodel. – Landrum

Oh ok I understand. Actually what I use for classes that inherit from my domain model is something like AddressExt. I don't use ViewModels inside ViewModels. So I would have AddressExt inside my ViewModel. – Equivalence

@shaftpolls What do you do if you need to for example present an object within a ViewModel that is not exactly the same as your domain model? – Landrum

When I create a class that inherit from one Entity of the Domain Model I call it (e.g AddressExt), so that's the name I use inside my ViewModel. – Equivalence

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 :-)

Ustulation

Yes, for the most part I also came to this conclusion, though the example I gave, address, is a poor example because usually if I have an address object I flatten it for my viewmodel. So that actually means that the number of child viewmodels I use are fewer than when I wrote this question. Nowadays, I usually just use child viewmodels to encapsulate aspects of the view that are different than the main content of the view. Anything else that is a model within the main model gets flattened. – Landrum