Stateless vs Stateful - Je pourrais utiliser des informations concrètes

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 à ce sujet, mais je ne trouve vraiment pas de bons articles à ce sujet. J'ai lu des dizaines d'articles sur le Web qui discutent vaguement du sujet, ou ils parlent de serveurs Web et de sessions - qui sont également `` avec état ou sans état, mais je suis intéressé par la conception sans état ou avec état des attributs dans le codage. . Exemple: j'ai entendu dire que les classes BL sont sans état de par leur conception, les classes d'entité (ou du moins c'est ce que je les appelle - comme Person (id, name, ..)) sont avec état, etc.

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

Quoi qu'il en soit, vraiment bref, voici ce que je sais de l'état de l'état vs apatride:

Stateful (comme WinForms): stocke les données pour une utilisation ultérieure, mais limite l'évolutivité d'une application, car elle est limitée par les limites du processeur ou de la mémoire

Stateless (comme ASP.NET - bien qu'ASP essaie d'être avec état avec ViewStates): une fois les actions terminées, les données sont transférées et l'instance est rendue au pool de threads (amorphe).

Comme vous pouvez le voir, ce sont des informations assez vagues et limitées (et assez concentrées sur l'interaction avec le serveur), donc je vous serais très reconnaissant de bien vouloir me fournir des informations plus savoureuses :)

Je vous suggère de partir d'une question dans StackOverflow qui traite des avantages de la programmation sans état. C'est plus dans le contexte de la programmation fonctionnelle, mais ce que vous lirez s'applique également à d'autres paradigmes de programmation.

La programmation sans état est liée à la notion mathématique de fonction qui, lorsqu'elle est appelée avec les mêmes arguments, renvoie toujours les mêmes résultats. Il s'agit d'un concept clé du paradigme de programmation fonctionnelle et j'espère que vous serez en mesure de trouver de nombreux articles pertinents dans ce domaine.

Les services Web RESTful sont un autre domaine que vous pourriez rechercher pour mieux comprendre. Celles-ci sont de par leur conception "sans état", contrairement à d'autres technologies Web qui tentent en quelque sorte de conserver l'état. (En fait, ce que vous dites qu'ASP.NET est sans état n'est pas correct - ASP.NET s'efforce de conserver l'état à l'aide de ViewState et doit certainement être caractérisé comme avec état. ASP.NET MVC, en revanche, est une technologie sans état). Il existe de nombreux endroits qui traitent de «l'apatridie» des services Web RESTful (comme ce blog), mais vous pouvez à nouveau partir d'une question SO .

Apatride signifie qu'il n'y a aucun souvenir du passé. Chaque transaction est effectuée comme si elle était effectuée pour la toute première fois.

Stateful signifie qu'il y a une mémoire du passé. Les transactions précédentes sont mémorisées et peuvent affecter la transaction en cours.

Apatride:

// The state is derived by what is passed into the function

function int addOne(int number)
{
    return number + 1;
}

Avec état:

// The state is maintained by the function

private int _number = 0; //initially zero

function int addOne()
{
   _number++;
   return _number;
}

Reportez-vous à: /software/101337/whats-the-difference-between-stateful-and-stateless

Une application avec état est une application qui stocke des informations sur ce qui s'est passé ou a changé depuis le début de son exécution. Toute information publique sur le "mode" dans lequel il se trouve, le nombre d'enregistrements traités, ou quoi que ce soit, le rend avec état.

Les applications sans état n'exposent aucune de ces informations. Ils donnent la même réponse à la même demande, fonction ou appel de méthode, à chaque fois. HTTP est sans état dans sa forme brute - si vous effectuez un GET vers une URL particulière, vous obtenez (théoriquement) la même réponse à chaque fois. L'exception, bien sûr, c'est lorsque nous commençons à ajouter l'état par-dessus, par exemple avec les applications Web ASP.NET :) Mais si vous pensez à un site Web statique avec uniquement des fichiers HTML et des images, vous saurez ce que je veux dire.

L'adjectif Stateful ou Stateless se réfère uniquement à l'état de la conversation, il n'est pas en relation avec le concept de fonction qui fournit la même sortie pour la même entrée. Si tel est le cas, toute application Web dynamique (avec une base de données derrière elle) serait un service avec état, ce qui est évidemment faux. Dans cet esprit, si je confie la tâche de garder l'état conversationnel dans la technologie sous-jacente (telle qu'une session coockie ou http), j'implémente un service avec état, mais si toutes les informations nécessaires (le contexte) sont passées en paramètres, je '' m implémenter un service sans état. Il est à noter que même si le paramètre passé est un "identifiant" de l'état conversationnel (par exemple un ticket ou un sessionId) nous fonctionnons toujours sous un service sans état,

L'argent transféré en ligne d'un compte à un autre compte est avec état, car le compte de réception contient des informations sur l'expéditeur. La remise d'espèces d'une personne à une autre personne, cette transaction est sans état, car une fois l'argent reçu, l'identité du donneur n'est pas là avec l'argent liquide.

Juste pour ajouter les contributions des autres ... Une autre façon est de le regarder du point de vue d'un serveur Web et de la concurrence ...

HTTP est de nature sans état pour une raison ... Dans le cas d'un serveur Web, être avec état signifie qu'il devrait se souvenir de «l'état» d'un utilisateur pour sa dernière connexion, et / ou garder une connexion ouverte à un demandeur. Ce serait très coûteux et `` stressant '' dans une application avec des milliers de connexions simultanées ...

Être sans état dans ce cas a une utilisation efficace évidente des ressources ... c'est-à-dire prendre en charge une connexion en une seule instance de requête et de réponse ...

Nous rendons les Webapps pleines d'état en remplaçant le comportement sans état HTTP en utilisant des objets de session. Lorsque nous utilisons des objets de session, l'état est conservé mais nous utilisons toujours uniquement HTTP.

J'ai eu le même doute sur la conception de classe sans état v / s avec état et j'ai fait quelques recherches. Je viens de terminer et mes résultats ont été publiés sur mon blog

• Les classes d'entité doivent être avec état
• Les classes helper / worker ne doivent pas être avec état.