Présentation des singletons de session

Les singletons furent l’une des features les plus remarquées de 4D 20 R5. Jusqu’alors, les développeurs pouvaient exploiter deux types de singletons :

• le singleton de processus, qui est unique pour chaque processus mais différent d’un processus à l’autre,
• et le singleton partagé, qui est unique sur l’ensemble de l’application.

Avec 4D 20 R7, nous lançons un nouveau type de singleton : le singleton de session !

Singletons de session HDI

Qu’est-ce qu’un singleton de session ?

Les singletons de session sont partagés au sein d’une session entière, mais varient d’une session à l’autre. Ils sont particulièrement utiles dans les environnements Web où les demandes d’un utilisateur sont traitées par des processus différents à chaque fois. Dans les environnements client-serveur, les singletons de session simplifient la création d’un singleton par utilisateur sur le serveur, ce qui permet de ne pas se soucier du processus qui l’utilise.

Les sessions dans 4D

Il existe quatre types de sessions dans 4D :

1. Les sessions client-serveur sont créées sur le serveur 4D chaque fois qu’un nouvel utilisateur se connecte à une application via un 4D Remote.
2. Les sessions Web, créées par le serveur Web pour traiter les requêtes HTTP d’un utilisateur, disponibles que si les scalable sessions ont été activées.
3. Les sessions REST, créées par le serveur REST pour traiter les requêtes REST d’un utilisateur, disponibles que si les scalable sessions ont été activées.
4. La session de procédure stockée est une session du serveur 4D qui gère l’exécution de toutes les procédures stockées.

Un cinquième cas de figure se produit lorsqu’aucune session n’existe. Cela ne se produit que sur un 4D Mono et que vous exécutez du code en dehors de toute requête web/REST.

Un cas d’utilisation classique : L’inventaire

Les singletons de session brillent dans des cas d’utilisation tels que les paniers d’achat, les liste d’éléments, les inventaires. Par exemple, considérons une situation chaque utilisateur a son propre inventaire :

//class ItemInventory
    property itemList : Collection:=[]

session singleton Class constructor()

shared function addItem($item:object)
    This.itemList.push($item)

En définissant la classe ItemInventory comme un singleton de session, chaque session – et donc chaque utilisateur– possède son propre ItemInventory. L’accès à l’inventaire de l’utilisateur est aussi simple qu’avec n’importe quel autre type de singleton :

$myItemInventory:=cs.ItemInventory.me

Le singleton renvoie l’inventaire de la session en cours depuis n’importe quel endroit de l’application. Modifier cet inventaire, en ajoutant ou en supprimant des objets par exemple, ne modifiera que l’inventaire de la session en cours, et donc de l’utilisateur en cours.

Considérations clés pour les singletons de session

Classes partagées :

La chose la plus importante à comprendre est que les singletons de session sont des classes partagées, puisque utilisés par plusieurs processus.

Sessions partagées :

Dernier point, mais non des moindres : Si vous réutilisez le même cookie pour une connexion web et une connexion REST, vous accéderez à la même session (qui passera d’une session web à une session REST) et donc au même singleton de session.

Conclusion

En résumé, les singletons de session fournissent un moyen simple et efficace de gérer des données spécifiques à l’utilisateur à travers différents processus dans 4D.

Si vous avez des questions ou si vous avez besoin d’aide, n’hésitez pas à participer à la discussion sur le forum 4D.