Come implementare lo stato della sessione in un'applicazione Web back-end?

1

Quando si utilizza un approccio con pattern non interattivo orientato ai servizi / MVC per l'architettura di sistema disaccoppiata, come viene implementato lo stato della sessione?

Ho pensato di creare il frontend di un'applicazione usando MVC (PHP / Ruby ecc.) e di inviare messaggi a un back-end della riga di comando che è l'applicazione vera e propria. Dal momento che voglio che l'applicazione offline abbia il pieno controllo della funzionalità, immagino che l'utilizzo di un sistema di gestione delle sessioni offline funzioni al meglio, il che al momento del login emette un ID che viene successivamente inviato all'applicazione a ogni richiesta. L'ID verrebbe memorizzato in un cookie sul lato client, proprio come un normale cookie di sessione. Dal momento che il frontend funziona attraverso le richieste HTTP comunque non ha senso farlo in altro modo per me.

Esistono alternative migliori a questo metodo che dovrei prendere in considerazione? Preferirei mantenere il sistema attuale completamente disaccoppiato dall'interfaccia utente web e anche pianificare l'implementazione di un'interfaccia utente desktop, quindi il pattern Interactors sembra essere il modo migliore per ottenerlo. Quello che sto cercando esplicitamente di evitare è "fare tutto nel nostro framework MVC! (Ed essere bloccato per sempre)" che sembra essere popolare al giorno d'oggi.

    
posta Seralize 15.04.2013 - 05:11
fonte

1 risposta

3

Ricevo ciò che stai chiedendo, ma l'implementazione che stai descrivendo è l'autenticazione remota, non lo stato della sessione. Lo stato della sessione non interessa se l'utente è autenticato o meno. Non vuoi che le sessioni richiedano l'autenticazione in generale.

Indipendentemente, torna alla domanda:

Ciò che ti interessa è lo stato della sessione distribuita. Tradizionalmente, questo è solitamente ottenuto da 1 di 2 approcci principali:

Un cluster di cache distribuita a cui i chiamanti possono accedere in remoto. I software particolari che fanno questo in realtà dipende dalle lingue con cui stai lavorando.

o

Le sessioni vengono mantenute su un database di back-end e le interazioni vengono gestite da un servizio o altra interfaccia di tipo proxy.

L'implementazione della memorizzazione nella cache è la più veloce, così come la natura della lettura dalla memoria (anche se distribuita), ma le sessioni non vengono mantenute tramite riavvii, arresti o guasti.

L'implementazione del database è un po 'più lenta ma è abbastanza fault-tolerant dal momento che sono persistenti nel database. Per compensare la differenza di velocità, le implementazioni del database solitamente utilizzano tabelle in memoria all'interno del database, poiché accelera notevolmente le letture e deve essere utilizzata un'attenta pianificazione dell'indicizzazione (a causa di molte modifiche dell'indice non necessarie gli indici diventano effettivamente controproducenti).

Un altro approccio che potresti considerare sarebbe gestire la gestione dello stato della sessione come un servizio basato sul web. Ciò consentirebbe di separare completamente le sessioni dall'applicazione e rispettare il principio del mvc di mantenere l'apolidia. Il servizio può essere chiamato tramite qualsiasi cosa che possa fare richieste http (anche jQuery o Ajax se si sceglie) e tutte le responsabilità potrebbero essere trasferite al cliente (in modo da poter avere la tua torta e mangiarla anch'essa:))

In realtà sto pianificando di provare quest'ultimo approccio solo per vedere quanto potrebbe essere esteso (ho preso in considerazione l'idea di un back-end HPC usando Casandra db e puntando a una strutturazione cloud-like dei servizi di sessione).

In entrambi i casi, ognuno di questi approcci ti consentirà di avere sessioni per tutti i canali offerti dalla tua applicazione, incluso il desktop:)

    
risposta data 15.04.2013 - 09:54
fonte

Leggi altre domande sui tag