Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Suggerimento
Questo contenuto è un estratto dell'eBook, Architect Modern Web Applications with ASP.NET Core and Azure, disponibile in .NET Docs o come PDF scaricabile gratuito che può essere letto offline.
"Legge di Atwood: qualsiasi applicazione che può essere scritta in JavaScript, verrà scritta in JavaScript."
- Jeff Atwood
Esistono due approcci generali alla creazione di applicazioni Web oggi: le applicazioni Web tradizionali che eseguono la maggior parte della logica dell'applicazione nel server e le applicazioni a pagina singola che eseguono la maggior parte della logica dell'interfaccia utente in un Web browser, comunicando con il server Web principalmente usando le API Web. Un approccio ibrido è anche possibile, il più semplice è ospitare una o più sottoapplicazioni simili a spa avanzate all'interno di un'applicazione Web tradizionale più grande.
Usare applicazioni Web tradizionali quando:
I requisiti lato client dell'applicazione sono semplici o persino di sola lettura.
L'applicazione deve funzionare nei browser senza supporto JavaScript.
La tua applicazione è rivolta al pubblico e trae vantaggio dall'essere scoperta tramite i motori di ricerca e dai riferimenti.
Usare una SPA quando:
L'applicazione deve esporre un'interfaccia utente avanzata con molte funzionalità.
Il tuo team ha familiarità con JavaScript, TypeScript o lo sviluppo di BlazorWebAssembly.
L'applicazione deve già esporre un'API per altri client (interni o pubblici).
Inoltre, i framework SPA richiedono una maggiore esperienza di architettura e sicurezza. Le applicazioni web moderne sperimentano un maggiore churn a causa degli aggiornamenti frequenti e dei nuovi framework client rispetto alle applicazioni web tradizionali. La configurazione dei processi di compilazione e distribuzione automatizzati e l'uso di opzioni di distribuzione come i contenitori possono essere più difficili con le applicazioni SPA rispetto alle app Web tradizionali.
I miglioramenti apportati all'esperienza utente resi possibili dall'approccio SPA devono essere valutati in base a queste considerazioni.
Blazor
ASP.NET Core include un modello per la creazione di interfacce utente avanzate, interattive e componibili denominate Blazor. Blazor lato server consente agli sviluppatori di compilare l'interfaccia utente con C# e Razor nel server e affinché l'interfaccia utente sia connessa in modo interattivo al browser in tempo reale usando una connessione SignalR persistente. Blazor WebAssembly introduce un'altra opzione per Blazor le app, consentendo l'esecuzione nel browser usando WebAssembly. Poiché si tratta di codice .NET reale in esecuzione in WebAssembly, è possibile riutilizzare codice e librerie da parti lato server dell'applicazione.
Blazor fornisce una nuova, terza opzione da considerare quando si valuta se creare un'applicazione Web di cui è stato eseguito il rendering puramente server o un'applicazione a pagina singola. È possibile creare comportamenti avanzati e simili a spa sul lato client usando Blazor, senza la necessità di uno sviluppo JavaScript significativo. Blazor le applicazioni possono chiamare API per richiedere dati o eseguire operazioni sul lato server. Possono interagire con JavaScript, se necessario, per sfruttare le librerie e i framework JavaScript.
Considera la creazione dell'applicazione Web con Blazor quando:
L'applicazione deve esporre un'interfaccia utente avanzata
Il team è più a proprio agio con lo sviluppo .NET rispetto allo sviluppo JavaScript o TypeScript
Se si dispone di un'applicazione Web Form esistente che si sta valutando di eseguire la migrazione a .NET Core o alla versione più recente di .NET, è possibile esaminare l'e-book gratuito perBlazor gli sviluppatori di Web Form per verificare se è opportuno valutarne la migrazione a Blazor.
Per altre informazioni su Blazor, vedere Introduzione a Blazor.
Quando scegliere le app Web tradizionali
La sezione seguente è una spiegazione più dettagliata dei motivi indicati in precedenza per la selezione di applicazioni Web tradizionali.
L'applicazione ha requisiti semplici, forse di sola lettura, per il lato client
Molte applicazioni Web vengono utilizzate principalmente in modo di sola lettura dalla maggior parte degli utenti. Le applicazioni di sola lettura (o prevalentemente di sola lettura) tendono a essere molto più semplici rispetto a quelle che gestiscono e modificano una grande quantità di stato interno. Ad esempio, un motore di ricerca può essere costituito da un singolo punto di ingresso con una casella di testo e una seconda pagina per la visualizzazione dei risultati della ricerca. Gli utenti anonimi possono effettuare facilmente richieste e non c'è bisogno di logica lato client. Analogamente, un'applicazione pubblica di un blog o di un sistema di gestione dei contenuti è in genere costituita principalmente da contenuti con scarso comportamento lato client. Tali applicazioni vengono compilate facilmente come applicazioni Web basate su server tradizionali, che eseguono logica sul server Web ed eseguono il rendering del codice HTML da visualizzare nel browser. Il fatto che ogni pagina univoca del sito abbia un proprio URL che può essere segnalibrato e indicizzato dai motori di ricerca (per impostazione predefinita, senza dover aggiungere questa funzionalità come funzionalità separata dell'applicazione) è anche un vantaggio evidente in tali scenari.
L'applicazione deve funzionare nei browser senza supporto JavaScript
Le applicazioni web che devono funzionare nei browser con supporto JavaScript limitato o assente dovrebbero essere scritte usando flussi di lavoro tradizionali delle applicazioni web (o almeno essere in grado di ricorrere a tale comportamento). Le applicazioni a pagina singola richiedono JavaScript lato client per funzionare; se non è disponibile, le applicazioni a pagina singola non sono una scelta ottimale.
Il team non ha familiarità con le tecniche di sviluppo JavaScript o TypeScript
Se il team non ha familiarità con JavaScript o TypeScript, ma ha familiarità con lo sviluppo di applicazioni Web sul lato server, probabilmente sarà in grado di distribuire un'app Web tradizionale più rapidamente rispetto a un'applicazione a pagina singola. A meno che l'obiettivo non sia imparare a programmare le applicazioni a pagina singola, o non vi sia la necessità dell'esperienza utente offerta da queste applicazioni, le app web tradizionali sono una scelta più produttiva per i team già esperti nella loro creazione.
Quando scegliere le SPA
La sezione seguente è una spiegazione più dettagliata di quando scegliere uno stile di sviluppo di applicazioni a pagina singola per l'app Web.
L'applicazione deve esporre un'interfaccia utente avanzata con molte funzionalità
Le applicazioni a pagina singola possono supportare funzionalità avanzate sul lato client che non richiedono il ricaricamento della pagina quando gli utenti esegono azioni o si spostano tra aree dell'app. Le applicazioni a pagina singola possono caricare più rapidamente, recuperando i dati in background; inoltre, le singole azioni degli utenti sono più reattive, poiché i ricaricamenti della pagina completa sono rari. Le applicazioni a pagina singola possono supportare gli aggiornamenti incrementali, salvando moduli o documenti parzialmente completati senza che l'utente debba fare clic su un pulsante per inviare un modulo. Le SPA possono supportare comportamenti complessi lato client, come funzioni di trascinamento della selezione, molto più facilmente rispetto alle applicazioni tradizionali. Le applicazioni a pagina singola possono essere progettate per l'esecuzione in modalità disconnessa, apportando aggiornamenti a un modello lato client che alla fine vengono sincronizzati di nuovo con il server dopo che viene ristabilita una connessione. Scegliere un'applicazione in stile SPA se i requisiti dell'app includono funzionalità avanzate che vanno oltre le tipiche offerte dai moduli HTML.
Spesso, le applicazioni a pagina singola devono implementare funzionalità integrate in app Web tradizionali, ad esempio la visualizzazione di un URL significativo nella barra degli indirizzi che riflette l'operazione corrente e consente agli utenti di aggiungere segnalibri o collegamenti diretti a questo URL per tornare. Le applicazioni a pagina singola dovrebbero anche consentire agli utenti di usare i pulsanti indietro e avanti del browser con risultati che non li sorprenderanno.
Il team ha familiarità con lo sviluppo JavaScript e/o TypeScript
La scrittura di applicazioni a pagina singola richiede familiarità con JavaScript e/o TypeScript e con le tecniche e le librerie di programmazione lato client. Il team deve essere competente nella scrittura di JavaScript moderno usando un framework SPA come Angular.
Riferimenti - Framework SPA
- Angular: https://angular.io
- React: https://reactjs.org/
- Vue.js: https://vuejs.org/
L'applicazione deve già esporre un'API per altri client (interni o pubblici)
Se si supporta già un'API Web per l'uso da parte di altri client, potrebbe essere necessario meno sforzo per creare un'implementazione spa che sfrutta queste API anziché riprodurre la logica in formato lato server. Le applicazioni a pagina singola usano ampiamente le API Web per eseguire query e aggiornare i dati mentre gli utenti interagiscono con l'applicazione.
Quando scegliere Blazor
La sezione seguente è una spiegazione più dettagliata di quando scegliere Blazor per l'app Web.
L'applicazione deve esporre un'interfaccia utente avanzata
Analogamente agli SPA basati su JavaScript, Blazor le applicazioni possono supportare un comportamento avanzato del client senza ricaricare le pagine. Queste applicazioni sono più reattive per gli utenti, recuperando solo i dati (o HTML) necessari per rispondere a una determinata interazione dell'utente. Progettate correttamente, le app lato Blazor server possono essere configurate per l'esecuzione come app lato Blazor client con modifiche minime dopo che questa funzionalità è supportata.
Il team è più a proprio agio con lo sviluppo .NET rispetto allo sviluppo JavaScript o TypeScript
Molti sviluppatori sono più produttivi con .NET e Razor rispetto a linguaggi lato client come JavaScript o TypeScript. Poiché il lato server dell'applicazione è già in fase di sviluppo con .NET, l'uso Blazor garantisce che ogni sviluppatore .NET del team possa comprendere e potenzialmente compilare il comportamento del front-end dell'applicazione.
Tabella decisioni
La tabella decisionale seguente riepiloga alcuni dei fattori di base da considerare quando si sceglie tra un'applicazione Web tradizionale, un'applicazione a pagina singola o un'app Blazor .
| Fattore | App Web tradizionale | Applicazione a pagina singola | Blazor App |
|---|---|---|---|
| Familiarità richiesta del team con JavaScript/TypeScript | Minima | Obbligatorio | Minima |
| Supporto di browser senza script | Supportata | Non supportato | Supportata |
| Comportamento minimo dell'applicazione Client-Side | Ben Adatto | Eccessivo | Vitale |
| Requisiti avanzati e complessi dell'interfaccia utente | Limitato | Ben Adatto | Ben Adatto |
Altre considerazioni
Le app Web tradizionali tendono a essere più semplici e hanno criteri di ottimizzazione del motore di ricerca (SEO) migliori rispetto alle app SPA. I bot dei motori di ricerca possono consumare facilmente il contenuto delle app tradizionali, mentre il supporto per l'indicizzazione delle SPA (applicazioni a pagina singola) potrebbe essere assente o limitato. Se l'app trae vantaggio dall'individuazione pubblica da parte dei motori di ricerca, questa è spesso una considerazione importante.
Inoltre, a meno che non sia stato creato uno strumento di gestione per il contenuto della SPA, potrebbe richiedere modifiche da parte degli sviluppatori. Le app Web tradizionali sono spesso più facili per gli utenti non sviluppatori di apportare modifiche, poiché gran parte del contenuto è semplicemente HTML e potrebbe non richiedere un processo di compilazione per l'anteprima o anche la distribuzione. Se è probabile che gli utenti non sviluppatori dell'organizzazione debbano mantenere il contenuto dell'app, un'app Web tradizionale può essere una scelta migliore.
Le SPA brillano quando l'app ha moduli interattivi complessi o altre funzionalità di interazione con l'utente. Per le app complesse che richiedono l'autenticazione per essere utilizzate e pertanto non sono accessibili dai crawler dei motori di ricerca, le SPA rappresentano un'ottima opzione in molti casi.
Collabora con noi su GitHub
L'origine di questo contenuto è disponibile in GitHub, in cui è anche possibile creare ed esaminare i problemi e le richieste pull. Per ulteriori informazioni, vedere la guida per i collaboratori.
