Какой подход выбрать для ViewModels?

Question

Я использую ViewModels с asp.net MVC3. Одна вещь, которая меня интересует, это предположить, что у меня есть объект с именем Customers, и у него есть экраны Add, Edit, Delete. Предположим, что все они имеют разные требования к свойствам.

Например, Добавить может иметь поле адреса, но экран редактирования может не иметь экрана редактирования, удаление может использовать имя клиента только больше, чем что-либо еще.

У меня вопрос, как вы создаете ViewModels для этого? Вы придерживаетесь подхода общих моделей представления между добавлением, редактированием и удалением, т. Е. Одним классом модели представления, который обрабатывает все для вас, или вы предпочитаете создавать классы / страницы представления моделей?

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

Недостатком одной модели / страницы является то, что она увеличивает время разработки. Куда мне идти?

Answer 1

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

Затем он может добавить эти поля (например, с помощью Chrome Dev Tools), чтобы внести в них изменения.

Самый безопасный способ избавиться от этой проблемы - просто иметь модели, в которых есть только те поля, которые можно изменять.

Тем не менее, продолжайте и используйте одну и ту же модель, если всем пользователям разрешено изменять все поля в модели. (И просто не показывать поля, которые не должны быть изменены)

Answer 2

Лучшие практики ViewModel ASP.NET MVC Просмотр образцов моделей

Answer 3

Мой подход к просмотру моделей заключается в использовании моделей общего представления, пока требования (транспортируемые данные) к представлению не станут другими. Это означает, что я использую модель общего представления, например, для CreateAddress и EditAddress, если все данные, переносимые в представление, совпадают. Если в представлении необходимо отобразить дополнительное поле, например, в представлении CreateAddress, я выполняю рефакторинг моделей представления и использую разные модели представлений для CreateAddress и EditAddress.

Например, для DeleteAddress я бы использовал отдельную модель представления с самого начала, потому что я знаю, что данные, отображаемые в представлении DeleteAddress, почти никогда не совпадают с данными в Create / EditAddress.

Другой подход заключается в использовании моделей динамического представления, поскольку модели представления должны / не должны реализовывать бизнес-логику и действовать как DTO между контроллерами, и просмотр этого подхода имеет некоторые преимущества (нет необходимости создавать свободную логику, отбрасывать DTO).

Answer 4

Это зависит от ситуации. если у вас есть похожие требования для разных экранов (проверка, свойства для визуализации и т. д.), вы можете использовать модель представления для разных представлений. Если есть различие в одном или двух свойствах, я все равно использовал бы ту же модель представления, и там, где эти свойства не нужны, я помещу их в скрытые входные данные, чтобы они возвращались с публикацией формы, не допуская нежелательных результатов. Как все знают, скрытые поля могут быть изменены, и разработчик должен решить, безопасно ли использовать скрытые поля. Тем не менее, если у меня разные требования к валидации для двух экранов, тогда я определенно должен использовать подход viewmodel / page. Вы можете комбинировать оба подхода в соответствии с требованиями, так как они говорят, что «нет лучшего способа сделать что-либо»