Почему JSF необходимо сохранять состояние компонентов пользовательского интерфейса на стороне сервера?
Поскольку HTTP не имеет состояния, а JSF - это состояние. Дерево компонентов JSF подвержено динамическим (программным) изменениям. JSF просто нужно знать точное состояние, которое было при отображении формы конечному пользователю, чтобы он мог успешно обработать весь жизненный цикл JSF на основе информации, предоставленной исходным деревом компонентов JSF, когда форма была отправлена обратно сервер. Дерево компонентов предоставляет информацию об именах параметров запроса, необходимых преобразователях / валидаторах, связанных свойствах управляемого бина и методах действий.
До какого момента времени JSF сохраняет состояние компонентов пользовательского интерфейса на стороне сервера и когда именно информация о состоянии компонента пользовательского интерфейса удаляется из памяти сервера?
Эти два вопроса, похоже, сводятся к одному и тому же. В любом случае, это зависит от реализации и также зависит от того, сохраняется ли состояние на сервере или клиенте. Немного приличная реализация удалит его, когда он истек или когда очередь заполнена. Например, Mojarra имеет ограничение по умолчанию в 15 логических представлений, когда сохранение состояния установлено на сеанс. Это настраивается с помощью следующего параметра контекста в web.xml:
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>15</param-value>
</context-param>
См. Также Часто задаваемые вопросы о Мохарре для других специфичных для Мохарры параметров и связанных с ними ответов com.sun.faces.numberOfViewsInSession vs com.sun.faces.numberOfLogicalViews
Поскольку вошедший в систему пользователь просматривает страницы, будет ли на сервере накапливаться состояние компонентов?
Технически, это зависит от реализации. Если вы говорите о переходе от страницы к странице (только запросы GET), то Мохарра не будет ничего сохранять в сессии. Однако если они являются запросами POST (формы с командными ссылками / кнопками), то Mojarra сохранит состояние каждой формы в сеансе до максимального предела. Это позволяет конечному пользователю открывать несколько форм на разных вкладках браузера в одном сеансе.
Или, если сохранение состояния установлено на клиент, JSF ничего не будет хранить в сеансе. Это можно сделать с помощью следующего контекстного параметра в web.xml:
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
Затем он будет сериализован в зашифрованную строку в скрытом поле ввода с именем javax.faces.ViewState формы.
Я не понимаю, в чем преимущество сохранения состояния компонента пользовательского интерфейса на стороне сервера. Не достаточно ли напрямую передать проверенные / преобразованные данные управляемым компонентам? Могу ли я попытаться избежать этого?
Этого недостаточно для обеспечения целостности и надежности JSF. JSF - это динамическая структура с единой точкой входа контроля. Без управления состоянием можно было бы подделать / взломать HTTP-запросы определенным образом (например, манипулировать атрибутами disabled, readonly и rendered), чтобы JSF мог выполнять разные - и потенциально опасные - вещи. Он даже будет подвержен атакам CSRF и фишингу.
И не будет ли это занимать слишком много памяти на стороне сервера, если существуют тысячи одновременных пользовательских сессий? У меня есть приложение, где пользователи могут публиковать блоги на определенные темы. Эти блоги довольно большие по размеру. Когда появится обратная запись или запрос на просмотр блогов, большие блоги будут сохранены как часть состояния компонентов. Это будет занимать слишком много памяти. Разве это не проблема?
Память особенно дешева. Просто дайте серверу приложений достаточно памяти. Или, если пропускная способность сети вам дешевле, просто переключите сохранение состояния на клиентскую сторону. Чтобы найти наилучшее совпадение, просто выполните стресс-тестирование и профилируйте свое веб-приложение с ожидаемым максимальным количеством одновременных пользователей, а затем предоставьте серверу приложений 125% ~ 150% от максимального измеренного объема памяти.
Обратите внимание, что JSF 2.0 значительно улучшил управление состоянием.Можно сохранить частичное состояние (например, только , вместо всего материала от <html> будет сохранен <h:form> до конца).Мохарра, например, делает это.Средняя форма с 10 полями ввода (каждое с меткой и сообщением) и 2 кнопками займет не более 1 КБ.При 15 сеансах просмотра это должно быть не более 15 КБ на сеанс.При ~ 1000 одновременных пользовательских сеансах это должно быть не более 15 МБ.
Ваша задача должна быть более сфокусированной на реальных объектах (управляемых компонентах и / или даже объектах БД) в области сеанса или приложения.Я видел много кодов и проектов, которые излишне дублируют всю таблицу базы данных в память Java в духе bean-объекта сессионной области, где Java используется вместо SQL для фильтрации / группировки / упорядочивания записей.При ~ 1000 записях это легко превысит 10 МБ за пользовательский сеанс .