117 votes

Stateless vs Stateful (sans état)

Je suis intéressé par les articles qui contiennent des informations concrètes sur la conception sans état et avec état dans la programmation. Je suis intéressé parce que je veux en savoir plus, mais je n'arrive pas à trouver de bons articles à ce sujet. J'ai lu des dizaines d'articles sur le web qui discutent vaguement du sujet, ou qui parlent de serveurs web et de sessions - qui sont aussi des sujets sur l'état ou l'absence d'état, mais je suis intéressé par la conception d'attributs sans état ou avec état dans le codage. Exemple : J'ai entendu dire que les classes BL sont sans état par conception, les classes d'entités (ou du moins c'est ainsi que je les appelle - comme Person(id, name, )) sont avec état, etc.

Je pense qu'il est important de le savoir parce que je crois que si je peux le comprendre, je peux écrire un meilleur code (par exemple, la granularité à l'esprit).

Bref, voici ce que je sais à propos de stateful vs stateless :

avec état (comme WinForms) : Stocke les données en vue d'une utilisation ultérieure, mais limite l'évolutivité d'une application, car elle est limitée par l'unité centrale ou la mémoire.

Sans état (comme ASP.NET - bien qu'ASP essaie d'avoir un état avec ViewStates) : Une fois les actions terminées, les données sont transférées et l'instance est renvoyée au pool de threads (Amorphous).

Comme vous pouvez le constater, il s'agit d'informations assez vagues et limitées (et plutôt axées sur l'interaction avec le serveur), je vous serais donc très reconnaissant si vous pouviez me fournir des éléments d'information plus savoureux :)

1voto

Ken.Fukizi Points 177

Juste pour ajouter aux contributions des autres....Une autre façon de voir les choses est de les considérer du point de vue d'un serveur web et de la concurrence...

HTTP est sans état par nature pour une raison bien précise... Dans le cas d'un serveur web, le fait d'être à l'état pur signifie qu'il devrait se souvenir de l'"état" de l'utilisateur lors de sa dernière connexion et/ou maintenir une connexion ouverte avec un demandeur. Cela serait très coûteux et "stressant" dans une application avec des milliers de connexions simultanées...

Être apatride dans ce cas, l'utilisation efficace des ressources est évidente... c'est-à-dire qu'une connexion est prise en charge dans une seule instance de demande et de réponse... Il n'est pas nécessaire de maintenir les connexions ouvertes et/ou de se souvenir de quoi que ce soit de la dernière demande...

-3voto

Nous faisons en sorte que les applications Web soient dotées d'un état en surmontant le comportement HTTP sans état par l'utilisation d'objets de session.

-4voto

Joymon Points 707

J'avais le même doute sur la conception des classes avec ou sans état et j'ai fait quelques recherches. Je viens de terminer et mes conclusions ont été publiées dans mon blog

  • Les classes d'entités doivent avoir un état
  • Les classes d'aide et de travail ne doivent pas avoir d'état.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X