Применение атрибутов DataAnnotation к ViewModel из модели - PullRequest
2 голосов
/ 25 ноября 2010

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

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

Как мы получаем все эти атрибуты DataAnnotation из моделиобъект и на возможно урезанные свойства ViewModel, не выбрасывая принцип СУХОЙ на обрыв?

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

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

Ответы [ 2 ]

1 голос
/ 25 ноября 2010

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

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

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

Кроме того, правильно ли мы считаем, что не следует использовать TryUpdateModel против сущности, которую мы извлекаем из БД?

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

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

0 голосов
/ 25 ноября 2010

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

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

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

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

...