Как стать автором
Обновить

Комментарии 9

Скажите пожалуйста, а зачем показывать пользователям «Чтение запрещено», если можно совсем не показывать? Это как показать конфетку, но не отдать.

Мне кажется, что лучше было бы создавать вьюхи где ненужные поля скрывались бы автоматически, либо специализированную View/PartialView для каждой роли.
Для каждой роли делать отдельное представление бывает не приемлемо, если ролей большое количество и у каждой своя область видимости. А сообщение выводить бывает нужно для того, чтобы отличать поля в которых ничего не введено, к примеру Null, от тех, которые явно скрыты.
Я бы вместо DenyReadRoles использовал Read(Roles=«Admin, etc»). Это как-то больше согласуется с атрибутом Authorize.
Такое не подойдет при динамическом назначении прав чтения для пользователей. Как один из вариантов: это хранение в модели помимо самих полей, еще и модификаторов доступа можно/нельзя. На виде использовать самописный хелпер для чтения полей такой модели, дабы не переносить логику отображения напрямую во вьюху.
С динамическим подходом согласен, но вместо хелперов можно было бы написать расширение по типу как здесь и просто не рендерить поле.
НЛО прилетело и опубликовало эту надпись здесь
Статья почти не отличается от предыдущей. Можете привести реальный пример, где это нужно?
Такой подход может быть полезен при разработке корпоративных приложений. Когда множество сотрудников работают с одними и теме же данными. Но, в зависимости от занимаемой должности, доступ к информации может различаться.
Атрибут должен реализовать интерфейс IMetadataAware, чтобы иметь возможность изменять метаданные модели.

Надо помнить, что это будет работать только с определенными метадата-провайдерами.

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