Соглашение об именах дочерних объектов ViewModel

Я строю ASP.Net приложение MVC, использующее подход ViewModel, чтобы держать мои доменные сущности отдельно от" моделей", используемых моим пользовательским интерфейсом. Я использую следующее Соглашение для именования моих классов ViewModel. ViewModelName = ViewName + "ViewModel". Например:

Index + ViewModel = IndexViewModel

до сих пор, так хорошо, это довольно распространенный шаблон, и есть много указаний по этой теме на StackOverflow и в других местах. Мой вопрос касается дочерних объектов, используемых моими ViewModels. Если моя ViewModel требуется класс со свойствами, идентичными моему объекту модели домена, я просто включаю модель домена в свою ViewModel. Например:

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

однако я не уверен, какое соглашение об именах использовать, когда мне нужен дочерний объект с разными свойствами из моей модели домена. Например, если Address нуждался в нескольких дополнительных свойствах, помимо того, что есть в модели домена адресов, как мне его называть? Я рассматривал AddressViewModel так:

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

но это просто мне кажется, что это неправильно. Мой инстинкт подсказывает, что суффикс ViewModel должен быть только для ViewModel верхнего уровня.

Я ищу предложения от других разработчиков о том, какие соглашения об именах они используют в этом сценарии, в частности, что бы вы назвали дочерним объектом в этом случае?

6
asp.net-mvc asp.net-mvc-viewmodel naming-conventions

1 ответов

Я собираюсь поставить ответ на это только потому, что никто другой не имеет! (Я знаю, что немного опоздала на эту вечеринку!)

Я обдумал это много раз и пробовал разные конвенций на протяжении многих лет. Единственное, что я понял, это то, что вы используете соглашение об именах...

Если ваше соглашение об именах должно суффиксировать ваши классы моделей пользовательского интерфейса с помощью "ViewModel", то дочерние модели должны иметь тот же суффикс, иначе вы нарушаете свой собственный съезд!

также допустим, у вас есть и адрес таблицы (или что там у вас) и клиент может иметь адрес и компанию и адрес и они оба используют ту же таблицу, то вы многие используют тот же ребенок модель как для родителя, так модели. Просто кажется правильным иметь AddressViewModel, однажды у вас может быть вид / частичный вид, который является моделью IEnumerable<AddressViewModel>

Я знаю, что на это нет правильного ответа, но это мой ответ: -)

1