Блог

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

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

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

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

Интересно, есть ли лучший подход для решения этой проблемы. Может быть, используя @Cacheable каким-то разумным способом, может быть, используя Spring WebFlow (с которым я никогда не работал), может быть, другие альтернативы, о которых я не могу думать. Есть ли какая-либо стратегия или технология, которые я мог бы использовать для этого? В настоящее время мы работаем с Spring 3.2. Мы также используем jQuery, на всякий случай, если это актуально.

Спасибо.

Написание ответа, поскольку я бы не вписался в комментарий:

• Для запросов POST нет ограничений на размер тела запроса. Ограничены только запросы GET (т. Е. Когда Параметры отправляются через параметры запроса). Здесь не нужно беспокоиться.

• Я не понимаю, почему вы не хотите использовать session (@sessionAttributes). Я бы сказал, что наличие многоступенчатых форм является одним из вариантов использования, для которого это было разработано.

• Хранение неполных объектов модели в базе данных также является хорошим подходом, поскольку он очень близок к принципам REST. Мы использовали это несколько раз в нашей компании.

• Spring WebFlow также является хорошим подходом, если вы не хотите обрабатывать всю переходную логику самостоятельно. Однако SWF — это не такая простая технология для изучения, и вы должны учитывать этот факт в своих оценках усилий.

• Существует другой подход, который, я бы сказал, становится все более популярным: динамически выполнять всю логику на одной веб-странице (например, с помощью AngularJS или какого-либо плагина jQuery) и отправлять результат в виде объекта JSON.

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

• Подход с одной динамической страницей (например, AngularJS) был бы хорош, если ваша общая архитектура приложения будет спроектирована таким образом.
• Spring WebFlow было бы неплохо, если вы знакомы с этой технологией или если вы планируете использовать больше многоступенчатых форм во всем приложении (т. Е. Я бы не стал использовать SWF, если мне нужно решить только один вариант использования с его помощью).
• Я бы, вероятно, пошел @SessionAttributes , если мне нужно быстро решить одну многоступенчатую форму. С этим связаны некоторые сложности (частичная проверка и частичное связывание, а именно)… так что, опять же, это может быть не самый простой подход в конце.

Spring Webflow прекрасно справится с вашим вариантом использования через свой flowScope.

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