MVC, где генерировать классы ViewModel?

Question

где должно происходить создание ViewModel? На уровне сервиса, в контроллере?

public class ObjectA {
 public string Name {get;set;}
 public IList<ChildB> Children {get;set;}
}

public class ObjectAViewModel {
 public ObjectA ObjectA {get;set;}
 public IList<ChildB> SelectableChildren {get;set;}
}

что если некоторые свойства объекта ObjectA должны быть рассчитаны во время выполнения?

public class ObjectA {
 public string Name {get;set;}
 public IList<ChildB> Children {get;set;}
 public CalculateMethod {get;set;}
 public decimal CalculatedValue {get;set;}
}

Допустим, что ObjectA.CalculatedValue рассчитывается из всех или некоторых из ChildB объектов в хранилище (не только связанных объектов), и что они рассчитываются по-разному в зависимости от значения CalculateMethod? Должен ли я расширить ObjectA, и в этом случае, где я должен положить его? вместе с ObjectA или как DTO где-то еще? И где должен состояться расчет?

Answer 1

Это кажется нетривиальным вопросом. Здесь есть отправная точка для размышления здесь и отсюда ссылки на другие обсуждения.

Я из Java и поэтому не имею непосредственного опыта вашего мира, но на концептуальном уровне мое мышление звучит так:

Модели ничего не знают о представлениях, они просто делают данные доступными, а также могут предоставлять доступные правила проверки, которые представления могут оказаться полезными. Например: вот некоторая дата, это поле является полем «Отдел». Вот список всех действительных отделов, поскольку в качестве модели я ничего не знаю о вас, мистер Вью, но думаю, что вы можете заполнить раскрывающийся список из этого списка отделов.

Проблема в том, что Модель может в конечном итоге посылать огромные объемы данных, которые не имеют значения для представления, читайте дальше ...

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

Следовательно, в самом общем сценарии для самого View дается Модель и она помогает себе в данных, которые ему необходимы. Таким образом, представление знает о модели, но не наоборот. Теперь, в качестве детали реализации, мы могли бы извлечь из этой взаимосвязи класс ViewModel, чтобы сохранить интересные данные для представления, и мы также могли бы извлечь логику в класс ViewModelFactory. Контроллер может фактически нести ответственность за выбор соответствующего ViewModelFactory на основе представления, к которому мы идем, и, следовательно, в некотором смысле Контроллер «делает» ViewModel, но логика - это (концептуальное) представление View.

Answer 2

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