Limité les applications Web au Stateless ou RESTFul,c'est nié l'existence de processus métier qui sont forcement basé sur une succession d'état.
Certes, tu peux stocker l'état du processus métier dans la base de donnée mais quand celui-ci n'a un sens que d'un point de vue applicatif. C'est un peu se compliquer.
Il y a plusieurs moyen de contourné le bouton Back. çà va de supprimer la barre utilisateur ou de contrôler que tu n'exécutes pas deux fois la même action (utilisation d'un cookie qui évolue à chaque action de l'utilisateur, d'un paramètre de formulaire).
Si tu ne fais que du Ajax, la bouton Back n'a plus aucun sens vu que tu n'as jamais changé de page web.
Enfin, même sur une application stateless, le bouton back est problématique. Comment gères-tu si la dernière opération modifié le modèle. Tu l'exécutes une deuxième fois ?
Enfin, les applications Stateless sont plus sensible cross-site-scripting.
Enfin très souvent, les promoteurs du Stateless parle de performance.
Le Statefull consomme juste un peu plus de memoire par session utilisateur.
Imaginons une application de E-commerce qui va géré un panier en Statefull.
L'application gère l'état applicatif de l'utilisateur. C'est à dire son panier, sa position dans l'application. A vue de nez, çà ne devrait pas prendre plus de 10 Ko et encore pour un bon client :).
10 Ko par session sur une machine de 16 Go , çà permet d'en supporter 1 600 000 clients :). C'est pas mal.
Personnellement, mes applications sont interne, j'en aurai jamais autant d'utilisateur.
Après, on peut se demander. Si il est plus rapide d'accéder à la mémoire pour afficher le contenu d'un panier ou d'obtenir un DataSource, lancer une requête SQL.
[^] # Re: Mon expérience
Posté par syj . En réponse à la dépêche Play! 1.0 est sorti. Évalué à 2.
Certes, tu peux stocker l'état du processus métier dans la base de donnée mais quand celui-ci n'a un sens que d'un point de vue applicatif. C'est un peu se compliquer.
Il y a plusieurs moyen de contourné le bouton Back. çà va de supprimer la barre utilisateur ou de contrôler que tu n'exécutes pas deux fois la même action (utilisation d'un cookie qui évolue à chaque action de l'utilisateur, d'un paramètre de formulaire).
Si tu ne fais que du Ajax, la bouton Back n'a plus aucun sens vu que tu n'as jamais changé de page web.
Enfin, même sur une application stateless, le bouton back est problématique. Comment gères-tu si la dernière opération modifié le modèle. Tu l'exécutes une deuxième fois ?
Enfin, les applications Stateless sont plus sensible cross-site-scripting.
Enfin très souvent, les promoteurs du Stateless parle de performance.
Le Statefull consomme juste un peu plus de memoire par session utilisateur.
Imaginons une application de E-commerce qui va géré un panier en Statefull.
L'application gère l'état applicatif de l'utilisateur. C'est à dire son panier, sa position dans l'application. A vue de nez, çà ne devrait pas prendre plus de 10 Ko et encore pour un bon client :).
10 Ko par session sur une machine de 16 Go , çà permet d'en supporter 1 600 000 clients :). C'est pas mal.
Personnellement, mes applications sont interne, j'en aurai jamais autant d'utilisateur.
Après, on peut se demander. Si il est plus rapide d'accéder à la mémoire pour afficher le contenu d'un panier ou d'obtenir un DataSource, lancer une requête SQL.