Naming Convention for ViewModel Child Objects
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 Address AddressViewModel { 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?
No comments:
Post a Comment