Применение атрибутов DataAnnotation к ViewModel из модели

Question

Мы помещаем все наши DataAnnotations в наш клиент класса Model. Затем мы выставляем экземпляр Customer как свойство на нашем связанном ViewModel вместе с некоторыми списками поиска для стран и т. Д. И отображаем это в нашем представлении. Пока все хорошо.

Затем мы читаем о SO и других источниках, что мы не должны передавать весь наш объект модели Customer в представлении по причинам, связанным с тем, чтобы предоставить только представление с минимальным минимумом, необходимым и, что более важно (для нас), чтобы предотвратить Возможные проблемы, когда ModelBinding потенциально вредоносных postbacks, которые добавляют дополнительную информацию, чтобы изменить наши свойства моделей, которые в противном случае не были доступны в представлении.

Как мы можем получить все эти атрибуты DataAnnotation с объекта модели и на возможно вырезанные свойства ViewModel, не бросая DRY-принцип над утесом?

Кроме того, правильно ли мы думаем, что мы не должны использовать TryUpdateModel против объекта, который мы вытаскиваем из db? Я предполагаю, что наш выбор состоит в том, чтобы либо использовать TryUpdateModel, и передавать список исключений свойств, который не кажется мне особенно элегантным, учитывая, что список является всего лишь параметром строки типа. Или, возможно, нам стоит покончить с TryUpdateModel и использовать такой инструмент, как AutoMapper, который более безопасен для типа?

Спасибо за любые мысли по этим вопросам.

Answer 1

Как мы можем получить все эти атрибуты DataAnnotation с объекта модели и на возможно вырезанные свойства ViewModel, не бросая DRY-принцип над утесом?

Вы не можете. Это цена, но я думаю, что это довольно дешево, потому что на самом деле в этой урезанной версии атрибуты проверки могут быть разными, и у вас могут быть разные свойства проверки в соответствии с требованиями представления. Приведем пример: New и Edit вид. В представлении Edit требуется объект Id, тогда как в представлении New не требуется, поскольку он будет назначен хранилищем данных (фактически, в вашей новой модели не может быть даже свойства Id).

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

Кроме того, правильно ли мы думаем, что мы не должны использовать TryUpdateModel против объекта, который мы вытаскиваем из db?

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

Что касается AutoMapper, то это должен быть инструмент для преобразования между вашими классами моделей (которые появляются в ваших подписях метода репозитория) и моделями представления, которые передаются и отображаются в представлении.

Answer 2

Я обнаружил, что размещение атрибутов проверки подлинности ТОЛЬКО на ViewModel и сохранение только объекта модели - лучший подход.

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

В услугах/классы бизнес-уровня, функции, которые обновляют или добавляют, принимают только необходимые значения для объектной модели (строки, ints и т. д.), но никогда не являются целым объектом. Класс сервиса отвечает за создание объекта.

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