Рекомендации по модели MVC - Как обрабатывать данные, не введенные пользователем

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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