Dans le framework Spring, nous pouvons créer des beans dans 6 spring bean scopes intégrés et vous pouvez également définir votre bean scope personnalisé. Sur ces six scopes, quatre sont disponibles uniquement si vous utilisez un ApplicationContext web-aware. Les scopes singleton et prototype sont disponibles dans tout type de conteneurs IOC.

Table of Contents1. Spring Bean Scope Types 1.1. singleton scope 1.2. prototype scope 1.3. request scope 1.4. session scope 1.5. application scope 1.6. websocket scope2. Custom thread scope3. Summary

Type de scopes de bean Spring

Dans Spring, le scope peut être défini à l’aide de l’annotation @Scope du bean Spring. Dressons rapidement la liste des six scopes de bean intégrés disponibles pour être utilisés dans le contexte d’une application Spring. Ces mêmes scope s’appliquent également au spring boot bean scope.

.

Scope Description
singleton (par défaut) Single instance d’objet bean par conteneur IoC de spring
prototype Opposé à singleton, il produit une nouvelle instance à chaque fois qu’un bean est demandé.
request Une seule instance sera créée et disponible pendant le cycle de vie complet d’une requête HTTP. Uniquement valable dans les Spring web-aware ApplicationContext.
session Une seule instance sera créée et disponible pendant le cycle de vie complet d’une session HTTP.

Uniquement valable dans les Spring conscients du web ApplicationContext.

application Une seule instance sera créée et disponible pendant le cycle de vie complet de ServletContext.

Uniquement valable dans Spring ApplicationContext conscient du web.

websocket Une seule instance sera créée et disponible pendant le cycle de vie complet de WebSocket.

Uniquement valable dans Spring ApplicationContext.

1.1. scope singleton

singleton est le scope par défaut du bean dans le conteneur spring. Il indique au conteneur de créer et de gérer une seule instance de la classe de bean, par conteneur. Cette instance unique est stockée dans un cache de tels beans singleton, et toutes les demandes et références ultérieures pour ce bean nommé renvoient l’instance en cache.

Exemple de bean singleton scope utilisant une config Java –

Exemple de bean singleton scope utilisant une config XML –

1.2. Scope prototype

prototype scope entraîne la création d’une nouvelle instance de bean à chaque fois qu’une requête pour le bean est faite par le code applicatif.

Vous devez savoir que les méthodes de cycle de vie du bean de destruction ne sont pas appelées prototype scoped beans, seules les méthodes de rappel d’initialisation sont appelées. Donc, en tant que développeur, vous êtes responsable du nettoyage des instances de bean scopées en prototype et de toute ressource qu’elles détiennent.

Exemple de configuration Java de la portée du bean prototype –

@Component@Scope("prototype")public class BeanClass {}

Exemple de configuration XML de la portée du bean prototype –

<bean class="com.howtodoinjava.BeanClass" scope="prototype" />
En règle générale, vous devriez préférer utiliser le prototype scope pour tous les beans à état et le singleton scope pour les beans sans état.
Pour utiliser des beans dans les scopes request, session, application et websocket, vous devez enregistrer les RequestContextListener ou RequestContextFilter.

1.3. request scope

Dans request scope, le conteneur crée une nouvelle instance pour chaque requête HTTP. Ainsi, si le serveur traite actuellement 50 requêtes, le conteneur peut avoir au maximum 50 instances individuelles de la classe bean. Tout changement d’état d’une instance ne sera pas visible pour les autres instances. Ces instances sont détruites dès que la requête est terminée.

Exemple de configuration Java de la portée du bean de requête –

@Component@Scope("request")public class BeanClass {}//or@Component@RequestScopepublic class BeanClass {}

Exemple de configuration XML de la portée du bean de requête –

<bean class="com.howtodoinjava.BeanClass" scope="request" />

Lire la suite : Comment fonctionnent les serveurs web ?

1.4. session scope

Dans session scope, le conteneur crée une nouvelle instance pour chaque session HTTP. Ainsi, si le serveur a 20 sessions actives, le conteneur peut avoir au maximum 20 instances individuelles de la classe de haricot. Toutes les requêtes HTTP au cours de la durée de vie d’une seule session auront accès à la même instance unique de bean dans cette portée de session.

Tout changement d’état d’une instance, ne sera pas visible pour les autres instances. Ces instances sont détruites dès que la session est détruite/terminée sur le serveur.

Exemple de configuration Java du scope du bean de session –

@Component@Scope("session")public class BeanClass {}//or@Component@SessionScopepublic class BeanClass {}

Exemple de configuration XML du scope du bean de session –

<bean class="com.howtodoinjava.BeanClass" scope="session" />

1.5. Application scope

Dans application scope, le conteneur crée une instance par application web runtime. Il est presque similaire au singleton scope, avec seulement deux différences à savoir .

  1. Le haricot scopé application est singleton par ServletContext, alors que le haricot scopé singleton est singleton par ApplicationContext. Veuillez noter qu’il peut y avoir plusieurs contextes d’application pour une seule application.
  2. application scoped bean est visible comme un ServletContext attribut.

Exemple de configuration Java de la portée du bean d’application –

@Component@Scope("application")public class BeanClass {}//or@Component@ApplicationScopepublic class BeanClass {}

Exemple de configuration XML de la portée du bean d’application –

<bean class="com.howtodoinjava.BeanClass" scope="application" />

1.6. Portée de websocket

Le protocole WebSocket permet une communication bidirectionnelle entre un client et un hôte distant qui a opté pour la communication avec le client. Le protocole WebSocket fournit une seule connexion TCP pour le trafic dans les deux sens. Cela est spécialement utile pour les applications multi-utilisateurs avec édition simultanée et les jeux multi-utilisateurs.

Dans ce type d’applications web, HTTP est utilisé uniquement pour la poignée de main initiale. Le serveur peut répondre avec le statut HTTP 101 (changement de protocole) s’il accepte – la demande de poignée de main. Si le handshake réussit, le socket TCP reste ouvert et le client et le serveur peuvent l’utiliser pour s’envoyer des messages.

Exemple de configuration Java de la portée du haricot websocket –

@Component@Scope("websocket")public class BeanClass {}

Exemple de configuration XML de la portée du haricot websocket –

<bean class="com.howtodoinjava.BeanClass" scope="websocket" />

Veuillez noter que websocket les beans scopés sont généralement des singletons et vivent plus longtemps que toute session WebSocket individuelle.

Périmètre de fil personnalisé

Spring fournit également un périmètre par défaut thread utilisant la classe SimpleThreadScope. Pour utiliser cette portée, vous devez l’enregistrer auprès du conteneur en utilisant la classe CustomScopeConfigurer.

Chaque requête pour un bean retournera la même instance au sein du même thread.

Exemple de configuration Java de l’étendue du bean thread –

@Component@Scope("thread")public class BeanClass {}

Exemple de configuration XML de l’étendue du bean thread –

<bean class="com.howtodoinjava.BeanClass" scope="thread" />

Résumé

Le framework Spring a fourni six étendues de bean spring et les instances ont une durée de vie différente dans chaque étendue. En tant que développeur, nous devons choisir judicieusement la portée de tout bean géré par un conteneur. De même, nous devons prendre des décisions judicieuses lorsque des beans avec des scopes différents se réfèrent les uns aux autres.

Essayez de vous souvenir de toutes les informations données ci-dessus pour répondre à n’importe quelle question d’entretien sur le scope du spring bean.

Happy Learning !!

Ce post a été utile?

Laissez-nous savoir si vous avez aimé ce post. C’est la seule façon de nous améliorer.
Oui
Non

.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *