Stateful Single Page Application con ASP.NET Core

1

Sto costruendo un semplice carrello acquisti con Angular e ASP.NET Core con. Non è richiesto l'accesso e l'utente può sempre effettuare il checkout ed effettuare il pagamento come ospite. Il front-end dovrebbe essere costruito con Angular, con 3 semplici componenti dinamici - Shop > Cassa > Percorso di pagamento in un unico percorso. Suppongo che mi affiderò al router Angular per gestire la transizione della pagina.

Tuttavia, sto pensando se utilizzare i cookie di sessione per mantenere lo stato dell'applicazione. Ad esempio, se l'utente ha aggiunto gli articoli nel carrello, un aggiornamento pulito non cancellerebbe i loro progressi e riporterebbe l'utente all'inizio. Se l'utente è in fase di pagamento, qualsiasi aggiornamento non riavvierà la propria sessione. So che alcuni preferiscono archiviare la sessione in Localstorage ma non è la mia preferenza.

Per la normale applicazione ASP.NET che esegue il rendering della vista tramite AJAX, non mi devo preoccupare di questo. Tuttavia, come posso assicurarmi che la SPA sia in stato e la sessione verrà sospesa se è inattiva per un certo periodo di tempo?

    
posta CalebC 21.06.2017 - 04:16
fonte

2 risposte

1

A un certo punto dovrai lavorare con la memorizzazione dei dati e doverli interrogare. Un modo comune per gestire ciò è creare servizi Web REST per gestire le esigenze dei dati. I servizi Web REST inviano e ricevono JSON, che è anche ciò che Angualar utilizza per il modello. È un'integrazione piuttosto fluida.

Se costruisci la tua applicazione come progetto API MVC di ASP.Net Core, puoi trarre un sacco di congetture dalla soluzione.

AngularJS 2 ha il concetto di "Servizi" che è il luogo dove mettere le chiamate AJAX effettive da inviare al tuo API REST. Puoi spegnerlo mentre stai elaborando il modo in cui desideri che l'interfaccia utente funzioni, quindi collegarlo al servizio web attuale.

Il vantaggio di questo approccio è che puoi facilmente ridimensionare l'applicazione aggiungendo più istanze dell'API REST dietro un firewall.

    
risposta data 21.06.2017 - 04:25
fonte
1

In questi giorni la tendenza è quella di memorizzare lo stato sul client. Questo ha più senso quando si scrive un fat client perché possiamo memorizzare lo stato in cui si trova la logica. Le chiamate al server saranno anche più semplici perché possono essere apolidi, con vantaggi in termini di distribuzione più semplice, scalabilità più semplice, debugging più semplice.

Nel client lo stato può essere salvato nella memoria di sessione che sopravviverà a un aggiornamento. Lo storage di sessione è ben supportato in tutti i browser moderni. Un'eccezione è il safari nella navigazione privata, un sensibile ripiego è quello di impedire l'aggiornamento e di confermare all'utente che vogliono eliminare le modifiche non salvate (come fa stackexchange)

    
risposta data 20.09.2017 - 17:04
fonte

Leggi altre domande sui tag