Einführung von Session Singletons

Singletons waren eine der herausragenden Funktionen von 4D 20 R5. Zuvor konnten Entwickler zwei Arten von Singletons nutzen:

• das Prozess-Singleton, das für jeden Prozess einzigartig, aber prozessübergreifend unterschiedlich ist,
• und das gemeinsame Singleton, das für die gesamte Anwendung eindeutig ist.

Mit 4D 20 R7 bringen wir eine neue Art von Singleton auf den Markt : das Session Singleton!

Was sind Session-Singletons?

Session Singletons werden innerhalb einer gesamten Sitzung verwendet, variieren aber zwischen den Sitzungen. Sie sind besonders nützlich in Web-Umgebungen, in denen die Anfragen eines Benutzers jedes Mal von verschiedenen Prozessen bearbeitet werden. In Client-Server-Umgebungen vereinfachen Session Singletons die Erstellung eines Singletons pro Benutzer auf dem Server, so dass man sich keine Gedanken darüber machen muss, welcher Prozess es verwendet.

Sitzungen in 4D

Es gibt 4 Arten von Sitzungen in 4D:

1. Client-Server-Sitzungen werden auf dem 4D Server erstellt, wenn sich ein neuer Benutzer mit einer 4D Remote verbindet
2. Web-Sitzungen, die vom Webserver erstellt werden, um die HTTP-Anfragen eines Benutzers zu bearbeiten, sind nur verfügbar, wenn die skalierbaren Sitzungen aktiviert wurden.
3. REST Sessions, die vom REST Server erstellt werden, um die REST Anfragen eines Benutzers zu bearbeiten
4. Die Stored-Procedure-Sitzung ist eine Sitzung des 4D Servers, die die Ausführung aller Stored Procedures übernimmt.

Ein fünfter Randfall tritt auf, wenn überhaupt keine Sitzung existiert. Er tritt nur auf, wenn Sie 4D Mono verwenden und Code außerhalb einer Web/REST Anfrage ausführen.

Ein klassischer Anwendungsfall: das Artikelinventar

Session Singletons glänzen in Anwendungsfällen wie Einkaufswagen, Listen von Elementen: das Artikelinventar. Betrachten wir zum Beispiel ein Artikelinventar, bei dem das Inventar jedes Benutzers einzigartig ist:

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

session singleton Class constructor()

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

Durch die Definition der Klasse ItemInventory als Session-Singleton hat jede Session – unddamit jeder Benutzer– ihr eigenes ItemInventory. Der Zugriff auf das ItemInventory des Benutzers ist genauso einfach wie bei jeder anderen Art von Singleton:

$myItemInventory:=cs.ItemInventory.me

Es gibt das ItemInventory der aktuellen Sitzung von überall in der Anwendung zurück. Das Ändern dieses ItemInventory, z. B. durch Hinzufügen oder Entfernen von Gegenständen, ändert nur das Inventarder aktuellen Sitzung –und damit das des aktuellen Benutzers.

Wichtige Überlegungen für Session Singletons

Gemeinsam genutzte Klassen:

Das Wichtigste ist, zu verstehen, dass Session Singletons gemeinsam genutzte Klassen sind, da sie von mehreren Prozessen verwendet werden.

Gemeinsame Sitzungen:

Last but not least: Wenn Sie dasselbe Cookie für eine Web- und eine REST-Verbindung wiederverwenden, greifen Sie auf dieselbe Sitzung zu (die von einer Web- zu einer REST-Sitzung wechselt) und damit auf dasselbe Sitzungssingleton.

Fazit

Zusammenfassend lässt sich sagen, dass Session Singletons einen einfachen und effizienten Weg bieten, benutzerspezifische Daten über verschiedene Sessions hinweg in 4D zu verwalten. Diese neue Funktion bietet eine einfache, skalierbare Lösung für den Aufbau organisierter Anwendungen, die Daten effizient über Sessions hinweg verwalten.

Wenn Sie Fragen haben oder Unterstützung benötigen, können Sie sich gerne an der Diskussion im 4D Forum beteiligen.