Presentación de los singletons de sesión

Los singletons han sido una de las funcionalidades más destacadas de 4D 20 R5. Anteriormente, los desarrolladores podían utilizar dos tipos de singletons:

• el singleton de proceso, que es único para cada proceso, pero diferente entre procesos,
• y el singleton compartido, que es único para toda la aplicación.

Con 4D 20 R7, estamos lanzando un nuevo tipo de singleton: ¡el singleton de sesión!

¿Qué son los singletons de sesión?

Los singletons de sesión son compartidos dentro de una sesión completa, pero varían entre sesiones. Son particularmente útiles en entornos web donde las peticiones de un usuario son gestionadas por diferentes procesos cada vez. En entornos cliente-servidor, los singletons de sesión simplifican la creación de un singleton por usuario en el servidor, eliminando preocupaciones sobre qué proceso lo está utilizando.

LAS Sesiones en 4D

Existen 4 tipos de sesiones en 4D:

1. Las sesiones cliente-servidor se crean en el servidor 4D cada vez que un nuevo usuario se conecta con un 4D Remote.
2. Las sesiones web, creadas por el servidor web para gestionar las peticiones HTTP de un usuario, sólo están disponibles si se han activado las sesiones escalables.
3. Las sesiones REST, creadas por el servidor REST para manejar las peticiones REST de un usuario.
4. La sesión de procedimientos almacenados es una sesión del servidor 4D que maneja la ejecución de todos los procedimientos almacenados

Un quinto caso extremo ocurre cuando no existe ninguna sesión. Sólo ocurre si se ejecuta 4D Mono y se ejecuta código fuera de cualquier petición web/REST.

Un caso de uso clásico: inventarioS

Los singletons de sesión brillan en casos de uso como los carritos de la compra, la lista de elementos: los inventarios. Por ejemplo, consideremos un caso donde el inventario de cada usuario es único:

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

session singleton Class constructor()

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

Al definir la clase ItemInventory como un singleton de sesión, cada sesión-y por tanto cada usuario-tiene su propio ItemInventory. Acceder al ItemInventory del usuario es tan sencillo como con cualquier otro tipo de singleton:

$myItemInventory:=cs.ItemInventory.me

Esto devolverá el ItemInventory de la sesión actual desde cualquier parte de la aplicación. Modificar este ItemInventory, añadiendo o eliminando elementos, por ejemplo, sólo modificará el inventario de la sesión actual y, por tanto, del usuario actual.

Consideraciones clave para los Singletons de sesión

Clases compartidas:

Lo más importante que hay que entender es que los singletons de sesión son clases compartidas, ya que son utilizados por múltiples procesos.

Sesiones compartidas:

Por último, pero no menos importante: si reutiliza la misma cookie para una conexión web y una conexión REST accederá a la misma sesión (que pasará de sesión web a sesión REST) y como tal al mismo singleton de sesión.

Conclusión

En resumen, los singletons de sesión proporcionan una manera simple y eficiente de gestionar los datos específicos del usuario a través de diferentes sesiones en 4D. Esta nueva funcionalidad ofrece una solución fácil y escalable para crear aplicaciones organizadas que gestionen eficientemente los datos a través de las sesiones.

Si tiene alguna pregunta o necesita ayuda, no dude en unirse a la discusión en el foro de 4D.