---

Febbraio 2019

Volume 34 Numero 2

Il presente articolo è stato tradotto automaticamente.

[Cutting Edge]

Gestione dei moduli in Blazor

Dal Dino Esposito | Febbraio 2019

ASP.NET Core Blazor è un C#-framework lato client, in base a compilare applicazioni a pagina singola (SPAs). A questo proposito, non è molto diverso da Angular, in quanto può interagire con qualsiasi back-end siano che espone gli endpoint raggiungibili tramite HTTP. In questo momento, tuttavia, Blazor è un lavoro in corso e tutt'altro che go-live.

Ciò premesso, alcune parti del Blazor fornite come parte di ASP.NET Core 3.0. I componenti di Razor è una speciale configurazione di un'applicazione Blazor che viene eseguito interamente sul server, side-by-side con un'applicazione ASP.NET Core classica che potrebbe essere costituita dai relativo back-end. Coesistenza di un'applicazione Web classica usta soprattutto per le attività di back-end e un livello di distinct presentazione Blazor basata sul server di ASP.NET semplifica alcuni scenari di programmazione e stabilisce una sorta di terreno tra un approccio SPA puro e una semplice approccio di server. In questo articolo, mi occuperò di occuparsi di moduli di input e la comunicazione client-server. Si inizierà con un breve sondaggio dei componenti di Razor.

Server-Side Blazor

Blazor è un framework di base progettato per ricevere e gestire gli eventi indipendentemente dall'ambiente circostante. Attualmente, gli scenari completamente supportati soli eseguono Blazor all'interno del thread dell'interfaccia utente di un browser host e all'interno del runtime di ASP.NET Core. Altri scenari realistici ancora a venire eseguono Blazor all'interno di un ruolo Web worker o anche in alcune piattaforme, ad esempio Electron-abilitazione di desktop. Hosting in un Web worker renderebbe Blazor una piattaforma adatta per le applicazioni Web progressive e non in linea, durante l'hosting in una piattaforma come Electron è inoltre plausibile. Ad esempio, ecco brevemente un confronto tra le istruzioni per l'avvio di Electron molto semplice (vedere https://github.com/electron/electron-quick-start) con ciò che accade quando viene eseguito un nuovo progetto Blazor lato server.

Codice sorgente di avvio rapido di Electron contiene il metodo seguente:

function createWindow () { 
  mainWindow = new BrowserWindow({width: 
    800, height: 600}) 
  mainWindow.loadFile(‘index.html’)
}

Il metodo è responsabile della creazione della finestra del browser e per il caricamento di un file HTML separato al suo interno. Tutto ciò che accade è uno scambio continuo di messaggi tra il mondo esterno (browser) e sulla shell più interna (le pagine HTML). Il framework che si trova tra appena gestisce il carico di messaggi di inoltro dei dati in modo appropriato. Vediamo cosa succede quando viene eseguita un'applicazione Blazor lato server, come illustrato nella figura 1.

Figura 1, la fase di caricamento di un'applicazione Blazor lato Server

In primo luogo, il browser carica il file index. HTML a livello di applicazione che definisce il layout di pagina principale (principalmente i tag HEAD) e, come parte del download, carica anche un piccolo file JavaScript denominato blazor.server.js. _Blazor/negoziare passaggio figura 1 indica il momento in cui viene stabilita una connessione di ASP.NET Core SignalR tra ambiente host del browser e l'app Blazor. Infine, la connessione viene aggiornata per i socket Web. Questo processo viene eseguito il passaggio finale acquisito dalla schermata di Fiddler nel figura 1.

In entrambi i casi, l'ambiente host carica un file di inizializzatore. Una volta stabilita la connessione, la logica dell'applicazione viene eseguita e produce qualsiasi HTML obbligatorio. In Blazor lato server, lato server HTML generato viene confrontato con il DOM attualmente sottoposto a rendering e vengono effettivamente aggiornati solo i frammenti necessari del DOM. Tutti gli aggiornamenti eseguiti tramite la connessione di SignalR.

Clic dell'utente acquisiti all'interno del browser aggira in altra direzione. Vengono creati ed inviati sul lato server, dove ha elaborati dal livello di interoperabilità Blazor JavaScript ed elaborati in eventi correlati al C# codice.

Visual Studio è disponibile un modello di progetto ad hoc per applicazioni Blazor lato server. Il progetto tipico include un progetto client e un progetto ASP.NET Core. Molto probabilmente, devi aggiungere un progetto di libreria .NET Standard per conservare le classi che devono essere condivisi tra il front-end e back-end.

Configurazione dell'App Client

La classe di avvio dell'applicazione client è quasi vuota:

public class Startup
{
  public void ConfigureServices(IServiceCollection services)
  {
  }

  public void Configure(IBlazorApplicationBuilder app)
  {
    app.AddComponent<App>(“app”);
  }
}

La modifica necessaria solo inserisce un riferimento a HttpClient in modo che le pagine Blazor sarà in grado di effettuare chiamate remote a HTTP:

public void ConfigureServices(IServiceCollection services)
{
  services.AddScoped<HttpClient>();
}

L'aggiunta di più rilevante per l'applicazione client è un componente che consente agli utenti di compilare e inviare un form. Nelle figura2 viene visualizzata l'applicazione dell'interfaccia utente generato dal pulsante di registrazione utente. È un semplice form HTML semplice che raccoglie un indirizzo di posta elettronica e una password da parte dell'utente e viene passato nuovamente a un back-end remoto.

Figura 2, il modulo di esempio

Ecco l'aspetto interessante è il markup è necessario generare il contenitore per i campi di input in figura 2. Anche se il contenitore viene effettuata e quacks come formato HTML, non è un form HTML true, come illustrato nella figura 3.

Figura 3 Markup per produrre un Form (Non-HTML)

<div class=”col-sm-6 col-md-4 offset-md-4”>
  <h3 class=”text-center login-title”>I Want To Be a New User</h3>
  <div class=”account-wall”>
    <div class=”form-signin”>
      <input type=”text” 
                   class=”form-control” 
                   name=”email” bind=”@Email” />
      <input type=”password” 
                   class=”form-control” 
                   name=”password” bind=”@Password” />
      <button class=”btn btn-primary 
                     onclick=”@TryRegister”>
        Sign me in
      </button>
    </div>
    <div class=”text-center”>@Message</div>
  </div>
</div>

Come può notare, il markup è HTML puro, ma non è necessario per un elemento del FORM. Al termine, il C# il codice in esecuzione nel client si occuperà di raccolta dei valori di input e in avanti per un endpoint remoto che forse (o forse no) sarà un back-end ASP.NET.

L'attributo di binding che viene visualizzato con il bidirezionale di garanzie di elementi INPUT binding tra la pseudo-maschera e le proprietà della pagina client Blazor associato. La funzione TryRegister è responsabile dell'invio di contenuto al back-end. Figura 4 Mostra il codice del blocco @functions della pagina client.

Figura 4 @functions blocco

@inject HttpClient Http...
@functions
{
  public string Email { get; set; }
  public string Password { get; set; }
  public string Message = “?”;

  public async Task TryRegister()
  {
    var input = new RegisterUserViewModel(Email, Password);
    try
    {
      var response = await Http.PostJsonAsync<CommandResponse>(
        “.../account/register”, input);
      if (response.Success)
        Message = response.Message;
    }
    catch (Exception e)
    {
      Console.WriteLine(e);
      throw;
    }
  }
}

Il contenuto dei campi di input vengono raccolti in una nuova istanza di un oggetto di trasferimento dei dati, ovvero RegisterUserViewModel: e serializzato come JSON tramite il metodo PostJsonAsync HttpClient. Il back-end riceve una richiesta HTTP POST, in cui il corpo è impostato come indicato di seguito:

{“email”:”...”,”password”:”...”}

In un'applicazione Blazor lato server, il back-end è in genere un'applicazione ASP.NET Core. In questo caso, la richiesta viene inoltrata a un endpoint del controller in cui si applica l'associazione di modelli. Di conseguenza, verranno acquisiti i dati inviati da un'istanza del server della stessa classe RegisterUserViewModel. Si noti tuttavia che il back-end non deve necessariamente essere un'applicazione ASP.NET Core. L'URL specificato nella chiamata tramite HttpClient deve essere un URL assoluto che può inviare dati a praticamente ovunque, inclusi alcuni legacy basata su Visual Basic back-end.

Configurazione dell'App Server

Nell'applicazione di esempio, l'applicazione server è una semplice API Web ASP.NET Core, protetta sarebbe la protezione di qualsiasi tali API Web. Ad esempio, potrebbe essere protetti da accessi non autorizzati tramite un token JWT funzionerebbe bene anche con i client non Web, tra cui i client desktop e per dispositivi mobili. Per ora, presupponiamo semplicemente che l'API Web consente l'accesso anonimo. Ecco il codice che necessario è stato ricevere ed elaborare i dati pubblicati Blazor:

public class AccountController : Controller
{
  [HttpPost]
  public IActionResult Register(
    [FromBody] RegisterUserViewModel input)
  {
    // Some work here      ...
    return Json(CommandResponse.Ok.AddMessage(“Done”));
  }
}

L'attributo FromBody svolge un ruolo chiave. Senza di essa qualsiasi chiamata effettuata verso l'endpoint, il modo in cui che il client Blazor esegue, potrebbe generare un'eccezione di associazione di modelli.

L'attributo FromBody indica al runtime di ASP.NET Core per associare il parametro per i dati trovati nel corpo della richiesta HTTP in ingresso. Si noti che possono esistere al massimo un parametro per ogni azione decorati con l'attributo FromBody.

ASP.NET Core delega la responsabilità di l'elaborazione del flusso di richiesta a una classe formattatore dedicato. La classe predefinita è JsonInputFormatter. Si noti anche che una volta il flusso della richiesta è stato letto per un parametro, non può essere letto nuovamente per un altro parametro. Il puntatore del flusso, infatti, presenta avanzate alla fine del corpo e non può essere spostato nuovamente.

La risposta dall'API Web è un'altra risposta JSON che Blazor client riceve e deserializzato nel modo seguente:

var response = await 
  Http.PostJsonAsync<CommandResponse>(absoluteUrl, input);

In questo frammento di codice, la risposta viene deserializzata in un'istanza del tipo CommandResponse e viene generata un'eccezione se si scopre risulti impossibile.

Una parola su sicurezza e autenticazione

La parte client di Blazor viene eseguito in un ambiente sandbox nello stesso modo da JavaScript eseguite codice. Il back-end di server è completamente disconnessa dal client e definisce il back-end raggiungibili solo in condizioni. L'app client Blazor deve essere conformi con qualsiasi livello di sicurezza siano soddisfatti intorno al back-end. A questo proposito, Blazor è un client basato su Web semplice che chiama un'API Web. Può eseguire l'autenticazione tramite cookie, ma più probabilmente dovrà eseguire l'autenticazione tramite token di connessione JWT.

Lo scenario Blazor lato server può essere un'altra storia, nel senso che è possibile abilitare gli scenari alternativi per l'autenticazione e autorizzazione. In questo punto, anche se è possibile ottenere rapidamente nella discussione nella non è stata eseguita ancora alcuna decisione bit.ly/2CdS74c. È probabile che vengano fornite alcune API predefinita per semplificare la creazione di form di accesso e disconnessione per le applicazioni Blazor lato server, nonché per altre operazioni di autenticazione comuni, ad esempio il ripristino di una password e l'interazione con l'oggetto interno sistema di appartenenze. È possibile che Blazor in qualche modo incorporerà predefinite dell'interfaccia utente di ASP.NET Core Identity. Ma anche in questo caso, non viene stabilito al momento della stesura di questo articolo.

Vantaggi e svantaggi dei componenti di Razor

Blazor lato server o Razor componenti, sarà la prima parte del Blazor per raggiungere lo stato di go-live al momento del rilascio come parte di ASP.NET Core 3.0. Alcuni sviluppatori potrebbero balk in svantaggi. Usato per configurare una soluzione di applicazione a singola pagina pura, Blazor può sembrare troppo distante dall'esperienza di programmazione degli sviluppatori Web ASP.NET classici. Inoltre, WebAssembly è necessario per eseguire C# all'interno del browser, che impone un costo in termini di download e l'avvio iniziale, durante il debug può essere problematico. Con una soluzione lato server, l'esperienza di sviluppo è più uniforme, con debug migliorato, compilazione JIT e un'API di dimensioni maggiori. Inoltre, sono supportati tutti i browser, indipendentemente dalla loro supporto nativo per WebAssembly. Per uno sviluppatore ASP.NET classico, l'aggiornamento solo le parti dell'interfaccia utente diventa quasi come semplice esempio in un'applicazione desktop.

Il problema è che tutto questo magic si basa su una connessione SignalR. Per visualizzare alcuni potenziali problemi. In primo luogo, vi sarà piuttosto un numero di richieste in entrata nella rete. Tutti gli aggiornamenti, infatti, richiedono un round trip. In secondo luogo, il server viene costretto a tenere traccia di tutti i client e il relativo stato. ASP.NET Core SignalR è inoltre disponibile come servizio di Azure, e ciò offre una base importante per garantire la scalabilità, ma nessuno ha provato out ancora nel mondo reale. Infine, non vi è alcun meccanismo incorporato per ripristinare lo stato dell'applicazione nel caso della connessione di SignalR. Qualsiasi soluzione persistente va bene, ma tutti rimarrà agli sviluppatori per il momento.

Tutto sommato, Blazor Alza di livello il modello di applicazione a singola pagina e il modello di applicazione a singola pagina è un po' problematico per molti sviluppatori. Blazor lato server (noto anche come, componenti di Razor) è un modo più intelligente e senza interruzioni per spostare a fasi verso l'architettura SPA. L'origine per questo articolo si basa su Blazor 0.7.0 ed è disponibile all'indirizzo bit.ly/2EpGF8d.

---

Dino Esposito ha scritto più di 20 libri e articoli 1,000-plus della sua carriera di 25 anni. Autore di "The congedo Sabbatico Break," Mostra un stile: manifestazioni teatrali, Esposito è occupato di scrittura di software per un mondo ecocompatibile come il strategist digitale in BaxEnergy. Seguirlo su Twitter: @despos.

Grazie al seguente esperto tecnico per la revisione dell'articolo: Jonathan Miller

---

Discutere di questo articolo nel forum di MSDN Magazine