Comment choisir la bonne lunette à haricots ?

Question

J'ai remarqué qu'il existait différents champs d'application pour les haricots, par exemple :

@RequestScoped
@ViewScoped
@FlowScoped
@SessionScoped
@ApplicationScoped

Quel est l'objectif de chacun d'entre eux ? Comment choisir une lunette de visée adaptée à mon haricot ?

Answer 1

Introduction

Il représente la portée (la durée de vie) du bean. Ceci est plus facile à comprendre si vous êtes familier avec le fonctionnement "sous les couvertures" d'une application web servlet de base : Comment fonctionnent les servlets ? Instanciation, sessions, variables partagées et multithreading .

---

@Request/View/Flow/Session/ApplicationScoped

A @RequestScoped vit aussi longtemps qu'un cycle unique de requête-réponse HTTP (notez qu'une requête Ajax compte également comme une requête HTTP unique). A @ViewScoped vit tant que vous interagissez avec la même vue JSF par des postbacks qui appellent des méthodes d'action renvoyant des null / void sans navigation/redirection. A @FlowScoped perdure tant que vous naviguez dans la collection de vues spécifiée et enregistrée dans le fichier de configuration du flux. A @SessionScoped dure aussi longtemps que la session HTTP établie. Une session @ApplicationScoped est en vigueur tant que l'application web fonctionne. Il est à noter que l'outil CDI @Model est en fait un stéréotype pour @Named @RequestScoped Les mêmes règles s'appliquent donc.

Le choix de la portée dépend uniquement des données (l'état) que le haricot détient et représente. Utiliser @RequestScoped pour les formulaires/présentations simples et non AJAX. Utiliser @ViewScoped pour des vues dynamiques riches basées sur ajax (validation basée sur ajax, rendu, dialogues, etc). Utiliser @FlowScoped pour le modèle "wizard" ("questionnaire") de collecte de données d'entrée réparties sur plusieurs pages. Utiliser @SessionScoped pour les données spécifiques au client, telles que l'utilisateur connecté et les préférences de l'utilisateur (langue, etc.). Utilisation @ApplicationScoped pour les données/constantes à l'échelle de l'application, telles que les listes déroulantes qui sont les mêmes pour tout le monde, ou les haricots gérés sans aucune variable d'instance et n'ayant que des méthodes.

Abuser d'un @ApplicationScoped bean pour les données à portée de session/vue/requête les rendrait communes à tous les utilisateurs, de sorte que n'importe qui pourrait voir les données de n'importe qui d'autre, ce qui est tout simplement erroné. L'utilisation abusive d'un @SessionScoped bean pour les données liées à la vue ou à la demande les rendrait communes à tous les onglets et à toutes les fenêtres dans une même session de navigation, de sorte que l'utilisateur final pourrait être confronté à des incohérences lorsqu'il interagit avec chaque vue après être passé d'un onglet à l'autre, ce qui n'est pas bon pour l'expérience de l'utilisateur. L'utilisation abusive d'un @RequestScoped pour les données de vue ferait en sorte que les données de vue seraient réinitialisées par défaut à chaque retour de page (ajax), ce qui pourrait entraîner le non-fonctionnement des formulaires ( Voir également les points 4 et 5 ici ). L'utilisation abusive d'un @ViewScoped pour les données relatives à la requête, à la session ou à l'application, et l'utilisation abusive d'un bean @SessionScoped bean pour les données relatives à l'application n'affecte pas le client, mais il occupe inutilement la mémoire du serveur et est tout simplement inefficace.

Notez que le champ d'application ne doit pas être choisi en fonction des performances, à moins que vous ne vouliez vraiment ont une faible empreinte mémoire et veulent être complètement sans état ; vous devrez utiliser exclusivement des @RequestScoped et manipuler les paramètres de la requête pour maintenir l'état du client. Notez également que lorsque vous avez une seule page JSF avec des données à portée différente, il est tout à fait possible de les placer dans des backing beans séparés dans une portée correspondant à celle des données. Les beans peuvent simplement accéder l'un à l'autre via @ManagedProperty dans le cas des haricots gérés par JSF ou @Inject dans le cas des haricots gérés par le CDI.

Voir aussi

• Différence entre les champs d'application View et Request dans les beans gérés
• Avantages de l'utilisation de JSF Faces Flow au lieu du système de navigation normal
• Communication dans JSF2 - Managed bean scopes

---

@CustomScoped/NoneScoped/Dependent

Cela n'est pas mentionné dans votre question, mais JSF (ancien) prend également en charge la fonction @CustomScoped y @NoneScoped qui sont rarement utilisés dans le monde réel. Les @CustomScoped doit renvoyer à un Map<K, Bean> dans un champ d'application plus large, qui a supplanté l'application Map#put() et/ou Map#get() afin d'avoir un contrôle plus fin sur la création et/ou la destruction des haricots.

Le JSF @NoneScoped et CDI @Dependent dure en principe aussi longtemps qu'une seule évaluation EL sur le haricot. Imaginons un formulaire de connexion avec deux champs de saisie renvoyant à une propriété du bean et un bouton de commande renvoyant à une action du bean, donc avec au total trois expressions EL, alors effectivement trois instances seront créées. Une avec le nom d'utilisateur, une avec le mot de passe et une sur laquelle l'action est invoquée. Normalement, vous ne voulez utiliser cette portée que pour les beans qui doivent vivre aussi longtemps que le bean dans lequel ils sont injectés. Ainsi, si un @NoneScoped o @Dependent est injecté dans un @SessionScoped Il vivra alors aussi longtemps que le @SessionScoped haricot.

Voir aussi

• Expiration d'une instance de managed bean spécifique après un intervalle de temps
• Qu'est-ce qu'un "none scope bean" et quand l'utiliser ?
• Quelle est la portée par défaut du Managed Bean dans une application JSF 2 ?

---

Flash scope

Enfin, JSF prend également en charge la portée flash. Elle est soutenue par un cookie vivant court qui est associé à une entrée de données dans la portée de la session. Avant la redirection, un cookie sera placé sur la réponse HTTP avec une valeur qui est associée de manière unique à l'entrée de données dans l'espace de session. Après la redirection, la présence du témoin de session est vérifiée et l'entrée de données associée au témoin est retirée de la session et placée dans la requête de la demande redirigée. Enfin, le cookie est supprimé de la réponse HTTP. De cette manière, la requête redirigée a accès aux données de la portée de la requête qui ont été préparées dans la requête initiale.

Ceci n'est en fait pas disponible en tant que champ d'application d'un haricot géré, c'est-à-dire qu'il n'existe pas de champ d'application pour les haricots gérés (managed bean). @FlashScoped . Le flash scope n'est disponible que sous forme de carte via ExternalContext#getFlash() dans les haricots gérés et #{flash} dans EL.

Voir aussi

• Comment afficher le message des visages dans la page redirigée ?
• Transmettre un objet entre les beans @ViewScoped sans utiliser les paramètres GET
• CDI manque @ViewScoped et @FlashScoped

Answer 2

Comme de JSF 2.x il y a 4 Bean Étendues:

• @SessionScoped
• @RequestScoped
• @ApplicationScoped
• @ViewScoped

La Portée de Session: La session portée persiste à partir du moment où une session est établie jusqu'à l'arrêt de session. A la fin de la session si l'application web invoque la méthode invalidate sur le Objet HttpSession, ou si elle expire.

RequestScope: La demande portée est de courte durée. Il commence quand une requête HTTP est soumis et se termine après la réponse n'est renvoyée pour le client. Si vous placez un managed bean en demande portée, une nouvelle l'instance est créée à chaque demande. Il est utile d'examiner la demande la portée si vous êtes préoccupé par le coût de la session de la portée de stockage.

ApplicationScope: Le champ d'application persiste pendant toute la durée de l'application web. Celui-ci est partagé entre tous les demandes et à toutes les séances. Vous placez géré les haricots dans l' la portée de l'application si un seul haricot doit être partagé entre tous les instances d'une application web. Le haricot est construit quand il est d'abord demandée par n'importe quel utilisateur de l'application, et il reste en vie jusqu'à ce que l'application web est supprimé à partir du serveur d'application.

ViewScope: portée de Vue a été ajouté en JSF 2.0. Un haricot dans l'étendue de l'affichage persiste alors que le même JSF page est réaffichée. (Le JSF spécification utilise le terme pour une page JSF.) Dès que l'utilisateur accède à une autre page, le haricot est hors de portée.

Choisissez la portée de vous en fonction de votre exigence.

Source: Base de Java Server Faces de la 3e Édition par David Geary & Cay Horstmann [n ° de Page. 51 - 54]