Stateless vs Stateful - Potrei usare alcune informazioni concrete

Sono interessato ad articoli che contengono alcune informazioni concrete sulla progettazione stateless e stateful nella programmazione. Mi interessa perché voglio saperne di più, ma davvero non riesco a trovare nessun buon articolo a riguardo. Ho letto dozzine di articoli sul web che discutono vagamente dell'argomento, o parlano di server web e sessioni - che riguardano anche stateful vs stateless, ma sono interessato alla progettazione di attributi stateless vs stateful nella codifica . Esempio: ho sentito che le classi BL sono senza stato in base alla progettazione, le classi di entità (o almeno questo è ciò che le chiamo io - come Person (id, name, ..)) sono stateful, ecc.

Penso che sia importante saperlo, perché credo che se riesco a capirlo, posso scrivere codice migliore (ad es. Granularità in mente).

Comunque, davvero breve, ecco quello che so su stateful vs apolidi:

Stateful (come WinForms): memorizza i dati per un ulteriore utilizzo, ma limita la scalabilità di un'applicazione, perché è limitata dalla CPU o dai limiti di memoria

Stateless (come ASP.NET, anche se ASP cerca di essere stateful con ViewStates): dopo che le azioni sono state completate, i dati vengono trasferiti e l'istanza viene restituita al pool di thread (Amorphous).

Come puoi vedere, sono informazioni piuttosto vaghe e limitate (e piuttosto concentrate sull'interazione con il server), quindi ti sarei davvero grato se potessi fornirmi qualche informazione più gustosa :)

Ti suggerisco di iniziare da una domanda in StackOverflow che discute i vantaggi della programmazione senza stato. Questo è più nel contesto della programmazione funzionale, ma ciò che leggerete si applica anche ad altri paradigmi di programmazione.

La programmazione senza stato è correlata alla nozione matematica di una funzione, che se chiamata con gli stessi argomenti, restituisce sempre gli stessi risultati. Questo è un concetto chiave del paradigma di programmazione funzionale e mi aspetto che tu possa trovare molti articoli rilevanti in quell'area.

Un'altra area che potresti ricercare per ottenere una maggiore comprensione sono i servizi web RESTful. Questi sono per progettazione "stateless", a differenza di altre tecnologie web che cercano in qualche modo di mantenere lo stato. (In effetti quello che dici che ASP.NET è senza stato non è corretto - ASP.NET si sforza di mantenere lo stato usando ViewState e deve essere sicuramente caratterizzato come stateful. ASP.NET MVC d'altra parte è una tecnologia senza stato). Ci sono molti posti che discutono di "apolidia" dei servizi web RESTful (come questo spot del blog), ma potresti ricominciare da una domanda SO .

Apolide significa che non c'è memoria del passato. Ogni transazione viene eseguita come se fosse stata eseguita per la prima volta.

Stateful significa che c'è memoria del passato. Le transazioni precedenti vengono ricordate e possono influire sulla transazione corrente.

Apolidi:

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

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

Stateful:

// The state is maintained by the function

private int _number = 0; //initially zero

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

Fare riferimento da: /software/101337/whats-the-difference-between-stateful-and-stateless

Un stateful app è quella che memorizza le informazioni su ciò che è successo o cambiato da quando ha cominciato a correre. Qualsiasi informazione pubblica su quale "modalità" si trova, o quanti record sono stati elaborati, o qualsiasi altra cosa, lo rende stateful.

Apolidi app senza stato non espongono nessuna di queste informazioni. Danno la stessa risposta alla stessa richiesta, funzione o chiamata di metodo, ogni volta. HTTP è senza stato nella sua forma grezza: se esegui un GET su un particolare URL, ottieni (teoricamente) la stessa risposta ogni volta. L'eccezione ovviamente è quando iniziamo ad aggiungere statefulness in cima, ad esempio con le app Web ASP.NET :) Ma se pensi a un sito Web statico con solo file HTML e immagini, saprai cosa intendo.

L'aggettivo Stateful o Stateless si riferisce solo allo stato della conversazione, non è in connessione con il concetto di funzione che fornisce lo stesso output per lo stesso input. In tal caso, qualsiasi applicazione web dinamica (con un database dietro di essa) sarebbe un servizio con stato, il che è ovviamente falso. Con questo in mente se affido il compito di mantenere lo stato di conversazione nella tecnologia sottostante (come un coockie o una sessione http) sto implementando un servizio stateful, ma se tutte le informazioni necessarie (il contesto) vengono passate come parametri io ' m implementando un servizio senza stato. Va notato che anche se il parametro passato è un "identificatore" dello stato della conversazione (ad esempio un ticket o un sessionId), stiamo ancora operando con un servizio senza stato,

Il denaro trasferito online da un account a un altro account è stateful, poiché l'account di ricezione contiene informazioni sul mittente. Consegnando denaro da una persona a un'altra, questa transazione è apolide, perché dopo che il denaro è stato ricevuto, l'identità del donatore non è presente con il denaro.

Solo per aggiungere i contributi degli altri ... Un altro modo è guardarlo da un server web e dal punto di vista della concorrenza ...

HTTP è di natura senza stato per una ragione ... Nel caso di un server web, essere stateful significa che dovrebbe ricordare lo 'stato' di un utente per la sua ultima connessione e / o mantenere una connessione aperta a un richiedente. Sarebbe molto costoso e "stressante" in un'applicazione con migliaia di connessioni simultanee ...

Essere apolidi in questo caso ha un evidente utilizzo efficiente delle risorse ... cioè supportare una connessione in una singola istanza di richiesta e risposta ... Nessun sovraccarico per mantenere le connessioni aperte e / o ricordare qualcosa dall'ultima richiesta ...

Rendiamo le webapp statefull sovrascrivendo il comportamento senza stato HTTP utilizzando oggetti di sessione. Quando usiamo gli oggetti di sessione, lo stato viene trasportato ma usiamo ancora solo HTTP.

Avevo lo stesso dubbio sulla progettazione di classi stateless vs stateless e ho fatto qualche ricerca. Appena completato e le mie scoperte sono state pubblicate nel mio blog

• Le classi di entità devono essere stateful
• Le classi helper / worker non dovrebbero essere stateful.