Utilizziamo i cookie per analisi, contenuti personalizzati e pubblicità.

Queste informazioni possono essere condivise con i nostri partner per fornire i servizi necessari.

Approfondisci

AccettoRifiuto

Dall'archivio articoli > ASP.NET Core

Introduzione a Blazor WebAssembly

di Marco De SanctisMarco De Sanctis, Moreno GentiliMoreno Gentili, in ASP.NET Core,

Alla recente Build 2020, Microsoft ha rilasciato ufficialmente anche il secondo hosting model per Blazor, denominato Blazor WebAssembly. Grazie ad esso, ora possimo eseguire codice C# direttamente nel browser per realizzare Web UI sofisticate senza l'uso di codice JavaScript.

Rispetto a Blazor Server, con Blazor WebAssembly il client non deve mantenere una connessione persistente con il server e perciò l'applicazione può funzionare anche in assenza di connettività. L'utente può quindi usare l'applicazione anche offline e, se sfruttiamo le API di HTML5, possiamo persistere i dati localmente per poi sincronizzarli con il server quando la connessione viene ristabilita. Inoltre anche la latenza tra l'interazione dell'utente e l'aggiornamento dell'interfaccia viene eliminata, dato che il codice viene eseguito direttamente nel browser, in maniera del tutto analoga a quanto accadrebbe se avessimo utilizzato JavaScript.

Figura 1

L'impatto di Blazor WebAssembly è notevole soprattutto dal lato della produttività: per la prima volta, infatti, possiamo eseguire codice C# e .NET Core all'interno del browser, creando pagine che siano fortemente tipizzate e condividendo librerie con la parte dell'applicazione che gira sul back end. Questo porta innumerevoli vantaggi, ad esempio quando abbiamo a che fare con logiche di validazione complesse che in precedenza dovevano essere implementate sia in C# (lato server) che in JavaScript per il client. Ovviamente potremo anche avvalerci degli strumenti di sviluppo a cui siamo abituati, quali Visual Studio e Visual Studio Code.

Blazor non è un nuovo Silverlight

Come è possibile eseguire codice C# sul browser? quali sono gli impatti per la sicurezza? e la compatibilità? Queste sono solo alcune delle domande che, verosimilmente, ci potremmo porre (o magari ci saranno poste) in fase di valutazione di una tecnologia innovativa come Blazor. Innanzi tutto sgombriamo subito la scena da uno dei dubbi più importanti: Blazor WebAssembly non richiede alcun plugin per il proprio funzionamento, e funziona nativamente su praticamente tutti i browser moderni, desktop e mobile. Questo grazie al fatto che è basato su un open standard come WebAssembly (WASM), che oramai ha un supporto pressochè totale, come risulta su questa pagina.

Lo standard WebAssembly definisce una serie di specifiche che i browser devono implementare per supportare l'esecuzione di codice assembly-like. Questo vuol dire che, in teoria, qualsiasi vendor di tecnologie di sviluppo può ora annoverare i browser web come possibile ambiente di esecuzione, a patto di scrivere un compilatore che produca codice WASM valido.

Blazor, in realtà, funziona in maniera leggermente differente, dato che Microsoft infatti ha predisposto un porting di Mono Runtime su WASM. In altre parole, la componente WASM di un'applicazione Blazor è il solo runtime, mentre il codice vero e proprio è contenuto nelle medesime DLL che possiamo eseguire sul server o sulla nostra macchina di sviluppo. Si tratta di una scelta che ha un impatto fondamentale, dato che qualsiasi libreria che implementi .NET Standard - e che abbia senso eseguire in un browser - può essere utilizzata in un'applicazione Blazor. Proprio come ogni altra applicazione .NET, anche con Blazor WebAssembly possiamo referenziare pacchetti NuGet e perciò realizzare funzionalità complesse grazie alle librerie prodotte da sviluppatori di terze parti. Inoltre, possiamo contare sul pieno supporto a funzionalità comuni integrate nel framework come autenticazione e localizzazione.

Figura 2

Come appena detto, l'unico requisito è che si tratti di codice che abbia senso eseguire in un browser. WebAssembly, infatti, ha una serie di vincoli di sicurezza piuttosto restrittivi, innanzi tutto il fatto che venga eseguito in una sandbox analoga a quella di JavaScript, dalla quale può interagire con il mondo esterno solo tramite API ben definite. A causa di questi vincoli, per esempio, Blazor e in generale WebAssembly, non hanno neanche la possibilità di accedere direttamente al DOM della pagina. Per questo motivo, infatti, oltre alla componente WASM, un'applicazione Blazor contiene anche un runtime JavaScript che, in maniera più o meno trasparente, viene utilizzato dall'engine di rendering per aggiornare il contenuto della pagina web.

Pertanto, usare una libreria come Microsoft.Data.SqlClient con Blazor non ha assolutamente senso, visto che il browser non sarà mai in grado di effettuare una connessione sulla porta 1433 di SQL Server. D'altro canto, sicuramente potremo invece sfruttare un package come Polly per implementare logiche di retry o fall back che sono incredibilmente utili in uno scenario potenzialmente disconnesso come quello di una Single Page Web Application.

4 pagine in totale: 1 2 3 4
Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn
Aggiorna

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti

Top Ten Articoli

Articoli via e-mail

Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!

In primo piano

.NET Conference Italia 2024 - Milano

.NET Conference Italia 2023 - Milano e Online

Le novità di .NET 7 e C# 11

Le novità in ASP.NET Core e Blazor con .NET 7

I più letti di oggi

In evidenza

Misc