La sessione web è "Bad Design"? Perché?

10

l'altro giorno stavo discutendo con un collega e lui è venuto fuori dicendo che usare la sessione utente in un'applicazione web è semplicemente sbagliato. Ho risposto che potrebbe essere sbagliato a seconda delle informazioni che stai memorizzando, altrimenti perché un servizio di sessione Web potrebbe essere fornito da Microsoft (stavamo parlando di ASP.NET).

Mi ha risposto, ancora una volta, che anche in MS potevano facilmente rispondermi che era un cattivo design. E che potesse mostrarmi dei white paper che lo dimostrano.

Purtroppo non ho più possibilità di contattare questo ragazzo, ma mi piacerebbe davvero capire di più sul suo punto di vista. Qualcuno ha informazioni / punti di vista su questo qui?

    
posta abx78 20.06.2013 - 15:54
fonte

3 risposte

9

Non penso che intendesse "cattiva progettazione" tanto quanto "cattiva pratica". In linea generale, un'applicazione web dovrebbe essere apolide come concepibilmente possibile. Anche se, ad esempio, potrebbe essere necessario conoscere le informazioni dell'utente per autorizzare la visualizzazione delle pagine, tali informazioni potrebbero essere salvate sulla macchina client sotto forma di cookie e il server semplicemente convalida le informazioni dell'utente ogni volta.

Sarebbe l'ideale, ma non puoi sempre contare sul fatto che il cliente sia in grado di salvare i cookie. Inoltre, implica la convalida dell'utente in modo stateless, che potenzialmente implica l'interrogazione delle informazioni dal database per una semplice richiesta di pagina. Spesso è più semplice salvare tali informazioni nella sessione.

Tuttavia, una volta attraversato il Rubicon, molti programmatori sono tentati di salvare non solo le informazioni di autenticazione nella sessione ma anche molte altre cose. Questo è un anti-modello e tende a rendere la tua applicazione web strongmente dipendente dallo stato, che è esattamente ciò che doveva essere evitato in primo luogo.

Alcuni programmatori farebbero affidamento su una tecnologia come Spring (se stai usando Java) per districare ciò che altrimenti sarebbe un casino di dipendenze, ma direi che questo rende solo più facile creare dipendenze piuttosto che eliminarle. Tali tecnologie dovrebbero aiutare il tuo sviluppo, non rendere il tuo anti-modello meno un problema.

Pertanto, una buona regola è che se si può scrivere senza stato, è probabilmente una buona idea farlo o si rischia di cadere in questa trappola. Ovviamente ti imbatterai in situazioni in cui è necessario, ma in generale, dovresti solo salvare le informazioni che altrimenti sarebbero difficili da riacquistare.

    
risposta data 20.06.2013 - 16:07
fonte
8

Penso che tu stia confondendo due diversi argomenti: 1) sessioni e 2) il modello di pagina dei webform di asp.net

È necessaria una sessione Web per autenticazione un utente. Idealmente una sessione dovrebbe essere utilizzata solo per questo scopo. Non è necessario memorizzare dati utente in una sessione (che si tratti sul server, in un cookie o come asp.net/webforms lo fa: all'interno della pagina stessa). Nessuno dovrebbe dire che una sessione web è cattiva, ma piuttosto, memorizzare i dati dell'utente in una sessione è una cattiva pratica. Le ragioni per non archiviare i dati utente sul server includono gli stessi motivi per evitare variabili globali. La memorizzazione dei dati dell'utente nei cookie o nella pagina può introdurre problemi di sicurezza. Anche l'uso del modello di pagina di asp.net non aderisce alla natura senza stato del web. Potresti fare una ricerca per scoprire di più sul perché le webform sono un cattivo design. D'altro canto, le sessioni sono una parte necessaria delle applicazioni web.

    
risposta data 20.06.2013 - 16:29
fonte
5

I controlli e la memorizzazione dello stato di sessione su una pagina sono essenzialmente un hack. È il caso della MS - una necessaria perché volevano essere in grado di fornire un ambiente di sviluppo in cui poter progettare le pagine come è possibile in ambienti winform.

Gli MS si sono spostati verso l'architettura MVC (ultima versione - MVC 4) che è più un ritorno a ciò che il protocollo dovrebbe essere effettivamente - senza stato.

Ci sono situazioni in cui lo stato di memorizzazione è ancora a portata di mano, ma dovrebbe essere inteso che questa è l'eccezione piuttosto che la regola.

    
risposta data 20.06.2013 - 16:12
fonte

Leggi altre domande sui tag