Singletons têm sido uma das caraterísticas de destaque de 4D 20 R5. Anteriormente, os desenvolvedores podiam aproveitar dois tipos de singletons:
- o singleton de processo, que é único para cada processo mas diferente entre processos,
- e o singleton partilhado, que é único em toda a aplicação.
Com 4D 20 R7, estamos lançando um novo tipo de singleton: o singleton de sessão!
O que são Session Singletons?
Singletons de sessão são compartilhados dentro de uma sessão inteira mas variam entre sessões. São particularmente úteis em ambientes Web onde os pedidos de um utilizador são tratados por processos diferentes de cada vez. Em ambientes cliente-servidor, os singletons de sessão simplificam a criação de um singleton por utilizador no servidor, eliminando preocupações sobre que processo o está a usar.
Sessões em 4D
Há 4 tipos de sessões em 4D:
- Sessões cliente-servidor são criadas no Servidor 4D sempre que um novo usuário se conecta com um 4D Remote
- Sessões web, criadas pelo servidor web para lidar com os pedidos HTTP de um usuário, só estão disponíveis se as sessões escaláveis tiverem sido ativadas.
- Sessões REST, criadas pelo servidor REST para lidar com os pedidos REST de um utilizador
- A sessão de procedimento armazenado é uma sessão do Servidor 4D que lida com a execução de todos os procedimentos armazenados
Um quinto caso extremo ocorre quando nenhuma sessão existe. Isso só acontece se executar 4D Mono e executar código fora de qualquer pedido web/REST.
Um caso de uso clássico: o inventário de itens
Session singletons brilham em casos de uso como carrinhos de compras, lista de elementos: o inventário de itens. Por exemplo, considere um inventário de itens em que o inventário de cada utilizador é único:
//class ItemInventory
property itemList : Collection:=[]
session singleton Class constructor()
shared function addItem($item:object)
This.itemList.push($item)
Ao definir a classe ItemInventory como um singleton de sessão, cada sessão– e, por conseguinte, cada utilizador – temo seu próprio ItemInventory. Acessar ao ItemInventory do utilizador é tão simples como com qualquer outro tipo de singleton:
$myItemInventory:=cs.ItemInventory.me
Isso retornará o ItemInventory da sessão atual de qualquer lugar na aplicação. Modificar esse ItemInventory, adicionando ou removendo itens, por exemplo, só modificará o inventário da sessão atual – e, portanto, do usuário atual.
Considerações importantes para Session Singletons
Classes compartilhadas:
A coisa mais importante a entender é que os singletons de sessão são classes compartilhadas, pois são usadas por vários processos.
Sessões partilhadas:
Por último, mas não menos importante: Se você reutilizar o mesmo cookie para uma conexão web e uma conexão REST, você acessará a mesma sessão (que mudará de uma sessão web para uma sessão REST) e, como tal, o mesmo singleton de sessão.
Conclusão
Em resumo, os singletons de sessão fornecem uma maneira simples e eficiente de gerenciar dados específicos do usuário em diferentes sessões em 4D. Essa nova caraterística oferece uma solução fácil e escalável para construir aplicações organizadas que gerenciam eficientemente dados entre sessões.
Se tem alguma pergunta ou precisa de assistência, sinta-se à vontade para juntar-se à discussão no fórum 4D.