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