Не создавал бы ViewModels для избыточности? В том смысле, что у меня есть моя модель домена, и мне нужно отобразить данные из нее на виду. Поэтому мы создаем ViewModels, добавляем DataAnnotations к нему и отображаем его в представлении. На данный момент у меня есть 2 объекта с почти идентичными данными.MVC viewmodel redundancy
Как уже говорилось, только самое тривиальное приложение может уйти с передачей своих моделей домена непосредственно в представление. Даже тогда это по-прежнему не очень хорошо по многим причинам.
Требования к вашему виду отличаются от требований к вашей модели данных. Например, у вас может быть поле, которое требуется в вашем представлении, но может быть нулевым в вашей модели vie. Если вы добавите атрибут `[Обязательный] ', то ваша модель теперь рассмотрит это поле с нулевым значением.
Тем не менее, моя самая большая причина никогда не использовать модели домена в представлениях для обеспечения безопасности. MVC позволяет вам размещать любое значение для него, а связующее устройство по умолчанию будет с радостью подключать значения, которые вы отправляете в модель, а это означает, что если у вас есть флаг IsAdmin, а кто-то отправил истинное значение для IsAdmin, тогда, когда вы сохранили изменения в модель, кто-то теперь администратор.
Первое правило веб-безопасности никогда не является доверительным вкладом от пользователя, и передача ваших моделей просмотра непосредственно в представление в основном отказывается от дезинфекции ваших данных.
Да, это форма избыточности. Но для достижения других целей часто требуется избыточность. В случае моделей, разделение моделей просмотра и моделей доменов помогает в достижении развязанной настройки между вашим представлением и хранилищем данных. И не так часто ViewModels являются точными копиями домена.
Это означает, что оно может измениться без какого-либо воздействия на другое. Я вижу случаи, когда это было бы ценно - изменения типа данных в таблице не требуют вызова для развертывания веб-приложения.
Итак, в то время как существует избыточность, это выбор дизайна для того, является ли система достаточно сложной, чтобы извлечь выгоду из этой избыточности.
Нет, использование ViewModel имеет свою собственную цель. Давайте подумаем о ситуации, когда ваше представление имеет две или более сущности из модели домена, без ViewModel, как вы собираетесь организовать данные? Данные, необходимые для просмотра, иногда не соответствуют модели домена, она может иметь меньше или больше информации, и иногда нам приходится предварительно обрабатывать данные из домена перед визуализацией (например, время даты в формате зависит от культуры клиента).
Кроме того, ViewModel помогает отключить веб-интерфейс от уровня домена. Объекты в модели домена - это не только представление данных (это единственная цель модели представления), но и операции, которые имитируют бизнес-правило, вы не хотите выставлять слишком много знаний о домене на уровень пользовательского интерфейса, который не нужен знать.
В 99% случаях ViewModels не приводят к избыточности.
Единственный 1%, который приходит мне на ум, - это простое приложение с анонимными моделями и страницами домена, на которых нет только одной модели на странице. Это характерно для страниц управления контентом.
В любом другом случае:
1) Ваши ViewModels сойдутся информацией из нескольких моделей домена
2) вы будете иметь логику, специфичную для вашего домена в доменных моделях
3) это не очень хорошая идея, чтобы смешать метаданные, такие как DataAnnotations в вашем домене
Благодарим за ответы. Какова была бы лучшая практика заполнения ViewModel (я знаю, что мы можем использовать Automapper). Я хотел бы знать, есть ли лучший способ загрузки ViewModel, кроме загромождения кода контроллера, чтобы сделать это. – itsbpk
@itsbpk. Я имею тенденцию использовать AutoMapper, хотя очень просто создать простые методы сопоставления. Вы можете реализовать их как методы расширения и просто сказать model.Map (otherModel). В любом случае, он не должен загромождать ваш контроллер. –