Путаница в использовании скрытых полей для постоянных данных - PullRequest
Новая
       22

Путаница в использовании скрытых полей для постоянных данных

2 голосов
/ 27 января 2012

Я немного запутался, как использовать скрытые поля для сохранения данных в моем приложении MVC.(Я также открыт для использования Session, если это имеет смысл.)

По сути, у меня есть приложение, которое задает ряд вопросов (которые могут поступать в разных порядках в зависимости от ответов пользователя).Эти вопросы предоставляются в виде частичного представления из одного контроллера (который вызывает вспомогательный метод, который понимает порядок того, как следует задавать вопросы).Когда пользователь отвечает на вопрос, я использую Ajax для отправки текущего ответа, который обновляет боковую панель своими текущими ответами.(Они могут вернуться в любое время, чтобы изменить ответ на вопрос.) Все ответы на мои вопросы хранятся в одном объекте модели «Ответы» (со свойством для каждого ответа).

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

Если это правильно, имеет ли смысл использовать объект Session?Я бы подумал, что было бы неэффективно (и очень не СУХОЙ) каждый раз обновлять каждое представление всеми типами моделей.Похоже, у людей противоречивые мнения по этому поводу, и я недостаточно образован в сохранении данных (и не использую какой-либо источник данных), чтобы быть уверенным в моем решении.

Ответы [ 3 ]

3 голосов
/ 27 января 2012

Если вы в конечном итоге получите скрытое поле для каждого поля / вопроса, имейте в виду, что это также увеличит полезную нагрузку, которую вы отправляете с (сам DOM) и отправляете на (переменные формы) сервер. Хотя это может быть неплохо для некоторых скрытых полей, я думаю, что через некоторое время оно станет довольно неуправляемым и неэффективным.

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

Не зная много о вашей ситуации, думаю, я бы больше склонялся к идее сессии.

Другая мысль, которая у меня возникла, заключалась в том, чтобы использовать одно скрытое поле, но сохранить в нем сериализованную в JSON версию вашей модели и использовать JavaScript на клиенте для его обновления, а также использовать Json.NET на стороне сервера для чтения это и работа с этим. Опять же, это действительно зависит от размера данных и от того, что вы с ними делаете.

Надеюсь, это поможет. Удачи!

UPDATE

Основываясь на вопросе в комментарии, вот как вы можете использовать JSON для хранения и передачи данных ... Примечание: я скорее специалист по jQuery, поэтому я использую это вместо чистого JavaScript для демонстрации .

В JavaScript у вас есть переменная для хранения вашего объекта: 

var questionJson = {};

Получив ответы на вопросы, вы добавите их в литерал объекта JavaScript: 

$('.question').blur(function(e){
  var questionName = $(this).attr('name');  //assume the field has an attribute name that is the question name identifier
  questionJson[questionName] = $(this).val();  //this will build up your object literal with name/value pairs of questions/answers
});

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

$('#submitButton').click(function(e){
  e.preventDefault();
  $('#hiddenFieldOfQuestionAnswerData').val(JSON.stringify(questionJson));
  $('#myQuestionAnswerForm').submit();
});

На стороне сервера извлеките скрытое поле из переменных формы и используйте Json.NET (или другой десериализатор Json) для десериализации строки JSON ... 

string json = Request.Form["hiddenFieldOfQuestionAnswerData"];
QuestionAnswerModel qaData = JsonConvert.DeserializeObject<QuestionAnswerModel>(json);
//go do stuff....

Надеюсь, это поможет.

0 голосов
/ 27 января 2012

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

Учитывать изменчивость скрытых полей и сеанса: потерять их относительно легко, в результате чегов сбое UX.Пользователь перенаправляет из цепочки HTTP-POST или случайно закрывает вкладку браузера, и карточный домик рушится.Невозможно снова собрать Шалтай-Болтай.

Мой выбор - использовать постоянное хранилище данных для каждой отправки.Таким образом, вы можете восстановить анкету, если скрытые поля или сессия потеряны.Если пользователь вошел в систему, вы можете связать данные с Principal.Name.Если нет, вы можете включить анонимный профиль (который также использует куки) и сохранить его против этого.В любом случае, если вы сохраняете данные вне диапазона с веб-сервера, вы можете восстановить анкету даже после того, как пользователь перезагрузит свой компьютер.

0 голосов
/ 27 января 2012

Поскольку вы уже имеете дело со скрытыми элементами, кажется, просто сериализуйте свою форму и отправьте ее с помощью ajax.Используйте загруженные ajax частичные представления для каждой загруженной формы.Лично я бы сделал объект ответа действительно набором вопросов / ответов.Наличие всех вопросов в качестве свойств не настраивается вообще, и изменения кода требуются каждый раз, когда добавляется вопрос.

Я бы сохранял прогресс на каждом шаге, а не полагался на форму для хранения.

повторная сериализация формы, если вы выбрали этот маршрут:

http://api.jquery.com/jQuery.post/

$.post("@Url.Action("Edit")", $("#yourform").serialize());
...