Введение
Представляет область действия (время жизни) компонента.Это легче понять, если вы знакомы с работой «под прикрытием» основного веб-приложения с сервлетами: Как работают сервлеты?Экземпляр, сеансы, общие переменные и многопоточность .
@Request/View/Flow/Session/ApplicationScoped
A @RequestScoped bean живет столько же, сколько один HTTP-запрос.Цикл ответа (обратите внимание, что Ajax-запрос также считается одним HTTP-запросом).Бин @ViewScoped живет до тех пор, пока вы взаимодействуете с тем же представлением JSF с помощью обратных передач, которые вызывают методы действия, возвращающие null / void без какой-либо навигации / перенаправления.Бин @FlowScoped живет до тех пор, пока вы перемещаетесь по указанной коллекции представлений, зарегистрированных в файле конфигурации потока.Компонент @SessionScoped живет столько времени, сколько установлен HTTP-сеанс.Бин @ApplicationScoped живет до тех пор, пока работает веб-приложение.Обратите внимание, что CDI @Model в основном является стереотипом для @Named @RequestScoped, поэтому применяются те же правила.
Выбор области действия зависит только от данных (состояния), которые содержит компонент, ипредставляет собой.Используйте @RequestScoped для простых и не AJAX форм / презентаций.Используйте @ViewScoped для расширенных динамических представлений с поддержкой ajax (проверка на основе ajax, рендеринг, диалоги и т. Д.).Используйте @FlowScoped для шаблона "мастера" ("вопросника") сбора входных данных, распределенных по нескольким страницам.Используйте @SessionScoped для специфических данных клиента, таких как зарегистрированный пользователь и пользовательские настройки (язык и т. Д.).Используйте @ApplicationScoped для данных / констант всего приложения, таких как выпадающие списки, которые являются одинаковыми для всех, или управляемые bean-компоненты без каких-либо переменных экземпляра и имеющие только методы.
Злоупотребление bean-компонентом @ApplicationScoped для сеанса / представления/ Запрос данных в области сделал бы его доступным для всех пользователей, так что любой может увидеть данные друг друга, что просто неправильно.Злоупотребление bean-компонентом @SessionScoped для данных области просмотра / запроса сделало бы его доступным для всех вкладок / окон в одном сеансе браузера, поэтому конечный пользователь может испытывать неудобства при взаимодействии с каждым представлением после переключения между вкладками, что плохо для пользовательского опыта,Злоупотребление bean-компонентом @RequestScoped для данных в области просмотра приведет к повторной инициализации данных в области просмотра в значения по умолчанию при каждой обратной передаче (ajax), что может привести к нерабочим формам ( см. Также пункты 4 и 5 здесь ).Злоупотребление компонентом @ViewScoped для запроса, данных сеанса или области приложения и использование компонента @SessionScoped для данных области приложения не влияет на клиента, но излишне занимает память сервера и просто неэффективна.
Обратите внимание, что область видимости не должна выбираться исходя из факторов, влияющих на производительность, если только у действительно недостаточно места в памяти и вы хотите полностью отказаться от состояния;вам нужно было бы использовать исключительно @RequestScoped bean-компоненты и скрипту с параметрами запроса для поддержания состояния клиента.Также обратите внимание, что если у вас есть одна JSF-страница с данными различной области, то вполне допустимо поместить их в отдельные компоненты поддержки в области, соответствующей области данных.Бины могут просто обращаться друг к другу через @ManagedProperty в случае управляемых бинов JSF или @Inject в случае управляемых бинов CDI.
См. Также:
@CustomScoped/NoneScoped/Dependent
Это не упоминается в вашем вопросе, но (устаревшая версия) JSF также поддерживает @CustomScoped и @NoneScoped, которые редко используются в реальном мире.@CustomScoped должен ссылаться на пользовательскую реализацию Map<K, Bean> в более широкой области действия, которая переопределяет Map#put() и / или Map#get(), чтобы иметь более точный контроль над созданием и / или уничтожением bean-компонента.
JSF @NoneScoped и CDI @Dependent в основном живут столько же, сколько и одна EL-оценка на бобе. Представьте себе форму входа в систему с двумя полями ввода, относящимися к свойству bean-компонента, и командную кнопку, относящуюся к действию bean-компонента, таким образом, в общей сложности с тремя выражениями EL, тогда фактически будут созданы три экземпляра. Один с установленным именем пользователя, один с установленным паролем и один, для которого вызывается действие. Обычно вы хотите использовать эту область только для bean-компонентов, которые должны существовать столько, сколько bean-компонент, в который он вводится. Так что если @NoneScoped или @Dependent вводится в @SessionScoped, то он будет жить так же долго, как боб @SessionScoped.
Смотри также:
Фотовспышка
Как и в прошлый раз, JSF также поддерживает объем флеш-памяти. Он поддерживается недолговечным cookie-файлом, который связан с вводом данных в область сеанса. Перед перенаправлением в ответе HTTP будет установлен cookie со значением, которое однозначно связано с вводом данных в область сеанса. После перенаправления будет проверено наличие файла cookie области флеш-памяти, а запись данных, связанная с файлом cookie, будет удалена из области сеанса и помещена в область запроса перенаправленного запроса. Наконец, cookie будет удален из ответа HTTP. Таким образом, перенаправленный запрос имеет доступ к данным области запроса, которые были подготовлены в начальном запросе.
На самом деле это недоступно как управляемая область действия bean, т. Е. Нет такой вещи, как @FlashScoped. Область действия флэш-памяти доступна только в виде карты через ExternalContext#getFlash() в управляемых компонентах и #{flash} в EL.
Смотри также: