Лучшая практика модели MVC — как обрабатывать данные, не вводимые пользователем

Итак, мой вопрос в том, что у меня есть модель. В моей модели есть некоторые данные, которые заполняются на основе идентификатора, переданного через URL-адрес и установленного в файл cookie, а остальные — это пользовательский ввод, который проверяется с помощью аннотаций данных.

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

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

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


model asp.net-mvc coding-style web-standards
person Josh    schedule 25.10.2010    source источник
comment
Я не могу использовать сессию. Это приложение работает в среде с балансировкой нагрузки. - Это не значит, что вы не можете использовать сеанс.   -  person John Farrell    schedule 26.10.2010
comment
Я бы предпочел не иметь дело с сеансом в распределенной среде, если мне это не нужно. :)   -  person Josh    schedule 26.10.2010

Ответы (3)


arrow_upward
2
arrow_downward

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

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

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

person Nick Larsen    schedule 25.10.2010
comment
В первую очередь меня беспокоит размещение данных в представлении в скрытых полях. Запрос может быть сфабрикован даже при использовании токена защиты от подделки. Моя проблема с использованием только URL-адреса заключается в том, что мои идентификаторы представляют собой простые значения int - их очень легко лечить. - person Josh; 26.10.2010
comment
Учитывая, что это приложение нуждается во всей возможной безопасности, я не добавляю никаких данных в форму. Я перестраиваю чувствительные части модели каждый раз, когда происходит действие. Кроме того, я проверяю, что пользователь связан с идентификатором, переданным через qs, на случай, если он попытается скрыться. Спасибо за ваше предложение. - person Josh; 27.10.2010

arrow_upward
1
arrow_downward

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

Если бы мне пришлось решить эту проблему, я бы использовал сеанс для хранения таких данных, связанных с сеансом. Если это среда с балансировкой нагрузки, вам потребуется распределенная обработка сеансов. Самый простой способ решить эту проблему — просто запустить службу состояний ASP.NET и начать использовать ее для обработки сеансов.

Если вам не нравятся технологии Microsoft, вы также можете использовать MemCached для хранения данных сеанса на серверах memcached. Для него есть провайдеры, например этот, к сожалению, похоже, он не находится в разработке больше.

person CodeTwice    schedule 25.10.2010

arrow_upward
1
arrow_downward

будет лучше, если вы получите его из своего DAL на каждом,
нехорошо помещать ненужные вещи в ваш html

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

или вы помещаете что-то в скрытые входные данные и с помощью firebug кто-то изменяет значения этих входных данных.

person Omu    schedule 26.10.2010
comment
Это действительно моя проблема с размещением данных в представлении с использованием скрытых полей. Изменить поля очень легко. - person Josh; 26.10.2010
comment
@ Джош, ты также можешь зашифровать свои идентификаторы или что-нибудь еще, что тебе нужно, и не помещать ненужные вещи в html. - person Omu; 26.10.2010