ViewModels и рендеринг
В нескольких демонстрационных проектах я видел, что ViewModels используется преобразовывать объекты данных в строки для использования в Представлении.
ViewModel будет обычно иметь конструктора, который получает один параметр - объект данных. Конструктор затем заполнит различные свойства ViewModel (главным образом строки и ints).
Это препятствует тому, чтобы любая сложная логика произошла в Представлении.
На первый взгляд это походит на хорошую идею мне, поскольку она более полно осуществляет разделение Представления от сложной логики.
Например, скажите, что мое представление пыталось представить свойство 'Size' объекта данных, при этом Размер был числом между 1 и 3 'Маленькими/Средними/Большими' представлениями.
Вместо того, чтобы иметь, если/оператор переключения бы, по моему мнению, у меня просто были бы 'SizeString' или что-то подобное в моем ViewModel, и, если/оператор переключения вошел бы в конструктора ViewModel.
Кто-либо не соглашается с этим подходом?
Было бы лучше использовать некоторый другой подход, такой как помощники? И если так, почему?
2 ответа
Целью ViewModel является представление (часть) сложной Доменной Модели, разложенной как примитивы, которые могут быть визуализированы в той или иной форме.
Эта декомпозиция должна где-то происходить. Она может включать в себя некую простую логику, такую как мой любимый пример: преобразование дискретного значения (OK, warning, error) в цвета (зеленый, желтый, красный). В этом суть того, что делает ViewModel, поэтому моим подходом по умолчанию было бы инкапсулировать эту логику в саму ViewModel.
Рассмотрим альтернативу: Если она не реализована в ViewModel, то где? Если вы поместите логику куда-нибудь еще, вы получите ViewModel, которая, по сути, просто структура без логики. Пусть ViewModel инкапсулирует преобразование/декомпозицию объекта домена, что хорошо сочетается с принципом Single Responsibility Principle .
Хотя это мой подход по умолчанию, я всегда знаю, что логика может потребоваться для повторного использования в нескольких ViewModel. В таких случаях это может указывать на то, что оригинальная ViewModel действительно сложная ViewModel, состоящая из нескольких вложенных просмотров. В таких случаях, Вы можете извлечь общую логику в суб-модель ViewModel, которая инкапсулирует только эту маленькую часть.
Он преобразует все в строку, потому что все в сети - это строка.
В принципе - модель представления должна быть в состоянии "готово к выводу". Если бы web был сделан только из чисел - мы бы все преобразовывали в инты/децималы.
Вся точка зренияМодель представления - для форматирования представляемых данных. В вашем случае - размер enum к маленькому/среднему/большому. Дело не в том, что отсоединение логики от представлений делает это ценным - это возможность одним способом, в одном месте прикрепить ваши данные для web.
Ответы на комментарий =>
Да, это хорошо сидит. Я делаю то же самое. Но что касается этого - я не против того, чтобы это тоже вошло во взгляды. Потому что представления и модели представлений являются последними в "цепочке зависимостей". Я достаточно прагматичен и полностью против только тех ситуаций, когда разработчик использует доменную модель в качестве модели представления, а требования к модели представления вступают в конфликт с доменной моделью (т.е. когда разработчик добавляет новые "объекты домена" только для целей представления)
.