ASP.NET MVC ModelMetadata - нарушаем ли мы разделение задач, когда помещаем атрибуты для описания пользовательского интерфейса в модель?

Question

Согласно этому сообщению в блоге"Объекты ModelMetadata создаются на основе данных, взятых из атрибутов, в основном из пространств имен System.ComponentModel и System.ComponentModel.DataAnnotations."

Помещая вспомогательные атрибуты пользовательского интерфейса в объекты модели ( DisplayFormat или UIHint ), разве мы не связываем модель и представление?

Answer 1

Я верю в это.Лично я сохраняю свою модель полностью независимой и пишу ViewModels, которая будет представлять мою модель в моем View.Затем назначьте все аннотации этим ViewModels.

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

Answer 2

Это во многом зависит от того, как вы определяете «связь». Вы уже «связали» свой View с вашей моделью в некотором смысле: ваш View использует те же свойства, что и ваша Model. Проблема не в «соединении», а в «что» и «как». Модель описывает что (должно отображаться), это зависит от вида, чтобы определить, как (сделать это). Если вы хотите строго следовать этому принципу, вам следует отказаться от подсказок пользовательского интерфейса.

Если вы хотите быть более практичным, иногда эти атрибуты могут упростить ваши представления (которые часто становятся слишком сложными). Так что решать вам.

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

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

Answer 3

Я так думаю.

Я создаю особые классы моделей представлений, которые представляют собой обмен информацией между браузером и сервером.Если состояние модели действительно, то я копирую значения или вызываю методы домена с этими значениями (для этого предназначена папка Models).Я никогда не помещаю специфичные для MVC атрибуты в мои доменные сущности.

Правило большого пальца, я храню свои сущности в отдельной сборке, которая ничего не знает о MVC.Методы действий MVC ... связыватель модели может сделать вам плохую шутку: D Если, например, у вас есть класс «Account», со свойством «IsAdmin», и вы выставляете эту сущность в форме регистрации, пользователь может попытатьсяпередайте произвольный параметр «IsAdmin = true» в строке GET или в полезной нагрузке POST, и механизм связывания модели MVC установит это свойство в вашей модели ... и ваш код, вероятно, сохранит эту информацию в базе данных.

Поэтому я считаю очень важным держать внимание на представлении моделей.

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

Cheers.