Maggio 2017

Volume 32 Numero 5

Il presente articolo è stato tradotto automaticamente.

Cutting Edge - ASP.NET Core per sviluppatori ASP.NET

Da Dino Esposito | Maggio 2017

Dino EspositoLa maggior parte dei aboutASP.NET entusiasmo che core è centrato sulla multi-piattaforma esperienza attiva. Si tratta di un traguardo di grandi dimensioni, e non è necessariamente un segno più se sei un utente ASP.NET normale con una codebase di grandi dimensioni di codice .NET 4. x e non si prevede di mantenere l'ambiente familiare di IIS e Windows. In questo caso, che cos'è il vantaggio di ASP.NET di base per tali uno sviluppatore ASP.NET regolari?

Inizialmente la nuova piattaforma potrebbe essere completamente diverso, come se qualcuno sneakily spostato altrove il formaggio notte. ASP.NET di base è nuovo, creandole da zero, in base alle procedure consigliate più moderni. Ciò può o non è possibile aumentare la potenza di programmazione e la capacità di risolvere i problemi dei clienti. Nessuno può realisticamente rispondere a questa domanda per proprio conto. Questa colonna tenta di cancellare completamente dallo stato attivo eventuali promozionale, benchmark e delle tecnologie e passare direttamente alla sostanza del elementi. Se si è bene con la piattaforma corrente, quali aspetti di base ASP.NET possono acquisire l'attenzione dell'utente?

Procedure comuni progettate in Framework

Quando i membri del team ASP.NET progettato il framework ASP.NET originale, che ha richiesto la maggior parte delle procedure consigliate di Active Server Pages e li decodificato in un nuovo framework. In questo modo, inoltre introdotte numerose nuove funzionalità, ad esempio compilato e codice gestito, i postback automatico e controlli server. ASP.NET Core segue lo stesso modello evolutivo.

Procedure di sviluppo comuni, ad esempio il caricamento iniziale dei dati di configurazione, inserimento di dipendenze, i pacchetti NuGet, autenticazione basata sulle attestazioni e miglioramenti Razor, sono funzionalità native del nuovo framework. Il nuovo framework include inoltre una procedura di avvio diverse, un middleware richiesta-risposta molto più modulare e anche un'infrastruttura più flessibile per la definizione di controller e visualizzazioni. ASP.NET di base è un framework multipiattaforma e consente di sviluppare applicazioni e includerli in Windows, nonché macOS e Linux. In un modo, ASP.NET Core obbliga a scrivere codice migliore in cui vengono forzati alcuni ulteriori livelli di separazione delle problematiche per impostazione predefinita. Non è tutto ciò che è possibile già ottenere con disciplina, tuttavia.

Per qualsiasi forma di sviluppo greenfield, ASP.NET di base è un'ottima scelta. Tuttavia, essendo un framework nuovo di zecca, dispone di alcuni costi iniziali inevitabile: Ogni membro del team debba imparare con esso. Inoltre, tutti gli utenti devono essere o imparare, con il modello di applicazione Model-View-Controller (MVC). Non tutti gli elementi che è possibile assegnare un'etichetta come sviluppo greenfield è nuovo. Riutilizzo dei blocchi di codice esistente, o almeno competenze (vale a dire dati access o sicurezza competenze), è consigliabile. La quantità di che è realisticamente possibile? Per rispondere a questo punto, ASP.NET di base è disponibile in due forme.

Versioni di ASP.NET di base

In figura 1, viene visualizzata la finestra di dialogo di Visual Studio 2015 per creare un nuovo progetto. (È essenzialmente lo stesso in Visual Studio 2017.)

Creazione di un nuovo progetto ASP.NET di base in Visual Studio
Figura 1 la creazione di un nuovo progetto ASP.NET di base in Visual Studio

Il primo modello verrà creato un progetto classico, non di base. I due modelli è possono creare un progetto ASP.NET di base per una versione diversa di .NET Framework. È il primo crossroad da affrontare il viaggio attraverso il territorio ASP.NET Core intatta.

Scelta di .NET Framework completo offre l'accesso a qualsiasi librerie di classi .NET esistenti, ma i limiti di hosting solo Windows e IIS. Figura 2 vengono riepilogate le differenze.

Figura 2 differenze fondamentali tra le versioni di ASP.NET di base

Framework Fatti
.NET Framework

ASP.NET MVC. Nessun WebForms

Nuovo ambiente di runtime e API di programmazione

Tutte le librerie per la versione selezionata di .NET Framework 

Solo hosting di IIS

.NET Core

ASP.NET MVC. Nessun WebForms

Nuovo ambiente di runtime e API di programmazione

Solo le librerie .NET Core

Hosting di più piattaforme

Indipendentemente dalla scelta di .NET Framework, l'adozione di ASP.NET Core espone il codice in un nuovo ambiente di runtime che unifica il runtime MVC basato su System. Web con il runtime di API Web ispirare dai principi di OWIN.

Suddivisione con IIS

Negli ultimi anni, il framework API Web ha tentato di risolvere la richiesta elevata di thin server consentono di esporre un'interfaccia RESTful per qualsiasi client HTTP attivato. API Web separato il modello di applicazione dal server Web e hanno portato alle specifiche OWIN, vale a dire un set di regole per server Web e applicazioni di interagire. API Web, tuttavia, è necessario un host e quando sono ospitati nel contesto di un'applicazione ASP.NET, aggiunge un altro ambiente di runtime per il footprint di memoria. Ciò accade nello stesso momento in cui il settore si sposta verso Super-semplice Web. Una semplice avanzato, server Web minimo è un endpoint HTTP per ottenere i contenuti più rapidamente possibile, solo un thin layer HTTP intorno a una logica di business. Tutto ciò che deve eseguire un server molto semplice processo di richiesta e restituire una risposta con alcun overhead tranne la logica di business.

Sebbene personalizzabili in base a una certa misura, l'ambiente di runtime ASP.NET corrente non è stato progettato per scenari simili. Per separare l'ambiente ASP.NET dall'ambiente di hosting è la chiave che trova in ASP.NET di base e il motivo per molte delle successive modifiche a livello di applicazione.

Avvio di un'applicazione

Dopo aver creato un nuovo progetto, la prima cosa che noterete è la mancanza di un file Global. asax e la presenza di un file program.cs. Come shocking come è possibile, un'applicazione ASP.NET di base è un'applicazione console semplice avviata dallo strumento driver dotnet (bit.ly/2mLyHxe).

Lo strumento dotnet è la chiave per il supporto multipiattaforma. Quando lo strumento da riga di comando (e il framework .NET Core) è disponibile per una nuova piattaforma, hosting riduce allo strumento di connessione del server Web. In IIS, la pubblicazione viene eseguita tramite un modulo ad hoc, il pacchetto di Hosting di .NET Core Windows Server (bit.ly/2i9cF4d). In quest'ultimo è in un server Ubuntu, si ottiene tramite un file di configurazione. Un esempio è reperibile in bit.ly/2lSd0aF.

Il server Web effettivamente funziona come un proxy inverso e comunica con l'applicazione console tramite una porta configurata. L'applicazione console si basa su un altro, più semplice, server Web che riceve le richieste e attiva la pipeline di applicazione interna in modo che vengano elaborati. Il codice seguente esegue il processo:

var host = new WebHostBuilder()
  .UseKestrel()
  .UseContentRoot(Directory.GetCurrentDirectory())
  .UseIISIntegration()
  .UseStartup<Startup>()
  .Build();
Host.Run();

Kestrel è il nome del server Web ASP.NET che riceve le richieste in ingresso e li elabora attraverso la pipeline. La chiamata di modulo di integrazione di IIS nel frammento di codice è solo necessario se si ospitano in IIS.

Con un proxy inverso intorno a ASP.NET di base dell'applicazione è consigliabile principalmente per motivi di sicurezza come il Kestrel Web interno non include server (al momento) i filtri per impedire, ad esempio, distribuite attacchi denial of service (DDoS). Dal punto di vista puramente funzionale, non è strettamente necessario un proxy inverso abilitato.

Come accennato, non è più un file Global. asax in un'applicazione ASP.NET di base e il ruolo del file Web. config viene notevolmente ridotto. In realtà, ha solo scopo di abilitazione di IIS per eseguire alcune operazioni per conto dell'applicazione, ad esempio come server di alcune pagine di errore statico. Gli aspetti quali la configurazione di gestione degli errori, registrazione, autenticazione e l'archiviazione dei dati di configurazione globali vengono eseguiti tramite una nuova API coordinata mediante la classe di avvio.

La classe di avvio

La classe di avvio contiene almeno un paio di metodi che l'host chiamerà durante la fase di inizializzazione:

public class Startup
{
  public void ConfigureServices(IServiceCollection services)
  public void Configure(IApplicationBuilder app)
  {
    app.Run(async (context) =>
    {
      await context.Response.WriteAsync(DateTime.Now)
    });
  }
}

Tramite il ConfigureServices metodo dichiarare i servizi di sistema dell'applicazione verrà utilizzato. Tecnicamente, il metodo è facoltativo, ma direi che uno è necessario in tutti gli scenari realistici. Per gli sviluppatori ASP.NET tradizionali, potrebbe essere Sconvolgente trovare che anche l'utilizzo del modello di applicazione MVC deve essere dichiarato e abilitato in modo esplicito. Ciò offre tuttavia la misura il livello di gravità modularità viene portata in ASP.NET di base:

public void ConfigureServices(IServiceCollection services)
{
  services.AddMvc();
}

Nel metodo configura, configurare i servizi richiesti in precedenza. Ad esempio, se è stato richiesto il servizio ASP.NET MVC, quindi nella configurazione è possibile specificare l'elenco delle route supportate. Si noti che è necessario inoltre una chiamata esplicita per consentire al server Web interno servire i file statici, inclusi i file comuni, ad esempio jQuery e Bootstrap:

public void Configure(IServiceCollection services)
{
  app.UseStaticFiles();
  app.UseMvcWithDefaultRoute();
  ...
}

La classe di avvio è anche possibile configurare il middleware dell'applicazione. Middleware è un nuovo termine con una sovrapposizione significativa concettuale con i moduli HTTP di ASP.NET corrente. In ASP.NET di base, il middleware funziona come indicato figura 3.

Il Middleware ASP.NET di base
Figura 3. il Middleware ASP.NET di base

È possibile registrare i blocchi di codice che la possibilità di pre e post-elaborazione qualsiasi richiesta in ingresso, vale a dire che ogni middleware può registrare il codice che viene eseguito prima o dopo il terminazione middleware, il metodo in esecuzione nel metodo configura della classe di avvio. Il modello generale è simile al modello ISAPI precedente di IIS. Ecco alcuni middleware di esempio:

app.Use(async (httpContext, next) =>
{
  // Pre-process the request
  // Yield to the next middleware
  await next();
  // Post-process the request   
});

Un middleware è una funzione che accetta un oggetto HttpContext e restituisce un'attività. L'elenco dei componenti middleware termina con il metodo Run. Rispetto alla pipeline ASP.NET corrente, la pipeline ASP.NET di base è bidirezionale e completamente personalizzabile. Inoltre, è vuoto per impostazione predefinita.

Servizi Web supersemplici

È chiaro che senza un metodo di esecuzione della pipeline, nessuna richiesta mai genererà una risposta. Allo stesso tempo, un metodo di esecuzione è sufficiente per produrre una risposta. Viene illustrato come breve pipeline può essere in un'applicazione ASP.NET di base. In Web Form ASP.NET e MVC, vengono eseguite numerose operazioni prima dell'esecuzione di codice per ogni richiesta. Risoluzione di un metodo del controller, ad esempio, piuttosto una procedura lunga che prevede un intero sottosistema riguarda l'invoker dell'azione. Il metodo Run, invece, è una chiamata diretta che segue immediatamente la ricezione della richiesta.

Si supponga che si desidera creare un file server che possiede un elenco di file di immagine (ad esempio, i flag) e restituisce un'immagine di dimensione corrette basata su alcuni parametri di input o proprietà del dispositivo. In ASP.NET di oggi, l'opzione più rapida probabilmente sta scrivendo un gestore HTTP ad hoc, ovvero una classe creata implementando l'interfaccia IHttpHandler mappato a una route di URL predefinita. Un gestore HTTP è più veloce rispetto a un endpoint ASPX e l'azione del controller MVC a causa della pipeline sottili. Include inoltre un footprint ridotto rispetto a un endpoint dell'API Web perché non richiede una pipeline OWIN secondo sopra la pipeline ASP.NET di base. (Questo non è il caso quando una soluzione API Web è ospitata all'esterno di IIS.)

In ASP.NET di base, creazione di un server di file effettivo è notevolmente più semplice ed efficace che mai. È sufficiente è creare la logica aggiuntiva (vale a dire, ridimensionamento o il ripristino) e associarlo al metodo di esecuzione del metodo ConfigureServices:

public void Configure(IApplicationBuilder app)
{
  app.Run(async (context) =>
  {
    var code = context.Request.Query["c"];
    var size = context.Request.Query["s"];
    var file = FindAndResizeFlag(code, file);
    await context.Response.SendFileAsync(file);
  });
}

Nell'esempio, partendo dal presupposto che abbiano una logica personalizzata per trovare un nome di file server corrispondente forniti parametri e quindi servono al chiamante tramite l'oggetto Response. Nessun altro codice, visibile o invisibile, è necessario. Francamente, non è stato effettivamente essere più facile di così.

Qualunque sia la sensazione di intestino sulla base di ASP.NET, che siate scettici o entusiasti su di esso, ASP.NET di base fornisce una funzionalità univoca non sono disponibili su qualsiasi piattaforma ASP.NET: creazione di un semplici servizi Web minimo. Allo stesso tempo, la stessa infrastruttura che consente di creare servizi Web molto semplici è la migliore garanzia che tutte le richieste possono essere servite con overhead minimo che è possibile eseguire in modo legittimo.

Conclusioni

Per essere produttivi sviluppatori ASP.NET di base, è sufficiente acquisire familiarità con un modello di applicazione più moderno di Web Form: pertanto, ASP.NET MVC o il modello di applicazione a singola pagina. Malgrado gli aspetti, la maggior parte delle modifiche di rilievo di ASP.NET Core sono presenti nell'ambiente di runtime. Informazioni sul modello di hosting e il middleware è sufficiente per analizzare la nuova piattaforma. Alla fine, è comunque sulla creazione di controller e visualizzazioni Razor di rendering. Alcuni elementi comuni quali l'autenticazione, registrazione e la configurazione sarà necessario un'API diversa, ma che solo di apprendimento richiede un certo tempo. Come è visualizzato, la sfida consiste nel trovare novità in essa è.


Dino Espositoè l'autore di "Microsoft .NET: Architettura delle applicazioni per l'azienda"(Microsoft Press, 2014) e"Moderne applicazioni Web con ASP.NET"(Microsoft Press, 2016). Technical evangelist per .NET e a piattaforme Android al JetBrains e spesso come relatore a eventi del settore in tutto il mondo, Esposito condivide la sua visione del software in software2cents.wordpress.com e su Twitter: @despos.

Grazie al seguente esperto tecnico Microsoft per la revisione dell'articolo: James McCaffrey