Cutting Edge - Indicazioni per le visualizzazioni di ASP.NET MVC Core

Da Dino Esposito | 2017 novembre

Dino Esposito Anche se ASP.NET Core possono sembrare molto simile alla classica MVC ASP.NET nell'area di, esistono numerose differenze dietro le quinte. Controller e visualizzazioni Razor anche le classi del modello possono spesso essere facilmente la migrazione con il minimo sforzo, ma l'architettura parlando, ASP.NET Core diversamente in modo significativo rispetto alle versioni precedenti non di base di ASP.NET.

Il motivo principale è la pipeline riscritta, che fornisce un'applicazione ASP.NET Core almeno due metodi per generare una risposta in formato HTML. Come previsto, un'applicazione può adottare il modello di programmazione MVC e generare codice HTML da visualizzazioni Razor richiamate tramite azioni del controller. In alternativa, un'applicazione può agire come un server Web molto sottile compilato in base a un middleware di terminazione e il codice in tale terminazione middleware possa eseguire tutti gli elementi, tra cui la restituzione di una stringa che il browser vengono trattati come HTML. Infine, in ASP.NET 2.0 Core è possibile utilizzare un approccio completamente nuovo, ovvero pagine Razor. Pagine Razor sono visualizzazioni Razor che non è necessario l'infrastruttura MVC, ma possono generare e rispondere HTML direttamente dalle file Razor.

In questo articolo, dopo una rapida descrizione server mini, terminazione middleware e pagine Razor, verrà invece e confrontare gli approcci che sono all'interno del modello di programmazione MVC per compilare le visualizzazioni. In particolare, verranno prese in nuove funzionalità di ASP.NET Core, inclusi gli helper di tag, Visualizza i componenti e inserimento di dipendenze (DI) e l'impatto sulle procedure di codifica effettivi.

HTML dal Middleware terminazione

Il middleware di terminazione è il blocco finale di codice nella pipeline ASP.NET Core che ottiene per elaborare una richiesta. In pratica, è una funzione diretta (lambda) in cui si elabora la richiesta HTTP per produrre una sorta di risposta rilevabile, se il testo normale, JSON, XML, binari o HTML. Ecco una classe di avvio di esempio per questo scopo:

public class Startup
{
  public void Configure(IApplicationBuilder app)
  {
    app.Run(async context =>
    {
    var html = BuildHtmlFromRequest(context);
    await context.Response.WriteAsync(html);
    });
  }
}

Scrittura di testo in formato HTML nel flusso di output della risposta e impostando il tipo MIME appropriato, si può servire HTML contenuto nel browser. Tutto avviene in modo molto diretto, senza filtri e nessun intermediazione, ma sicuramente ed è più veloce rispetto a qualsiasi elemento nelle versioni precedenti di ASP.NET. Terminazione middleware consente di controllare il flusso prima di qualsiasi altra opzione. Chiaramente, codifica un diritto di factory HTML nel middleware di terminazione è lontano da una soluzione flessibile e gestibile, ma funziona.

Pagine Razor

In ASP.NET 2.0 Core pagine Razor forniscono un ulteriore modo per gestire il contenuto HTML, richiamare direttamente un file di modello Razor senza dover passare attraverso un controller e dell'azione. Fino a quando il file di paging Razor si trova nella cartella delle pagine e il percorso relativo e il nome corrisponde all'URL richiesto, il motore di visualizzazione elaborerà il contenuto e genererà HTML.

Gli aspetti che differenziano effettivamente pagine Razor e visualizzazioni Razor è che una pagina Razor può essere un singolo file, in modo analogo a una pagina ASPX, che contiene codice e markup. Una pagina Razor è un file CSHTML contrassegnato con una direttiva @page che può essere associata a un modello di visualizzazione che eredita dalla classe PageModel fornita dal sistema. Come già accennato, tutte le pagine Razor andare nella cartella del progetto radice nuove pagine e routing segue uno schema semplice. L'URL con radice nella cartella delle pagine e l'estensione. cshtml viene rimossa dal nome file effettivo. Per ulteriori informazioni sulle pagine Razor, hanno un aspetto in bit.ly/2wpOdUE. Inoltre, per un esempio più avanzato, hanno un'occhiata msdn.com/magazine/mt842512.

Se si è abituati a lavorare con i controller MVC, prevedere che fondamentalmente inutile, probabilmente solo minima utile per i rari scenari in cui si dispone di un metodo del controller che esegue il rendering di una visualizzazione senza intorno a qualsiasi logica di business sono disponibili pagine Razor. D'altra parte, se si ha familiarità con il modello di applicazione MVC, pagine Razor forniscono un'altra opzione per la masterizzazione il framework di ASP.NET Core. Per alcune persone, pagine Razor offrono una barriera inferiore della voce di stato di avanzamento con il framework.

Helper di tag

La sintassi Razor è sempre stato essenzialmente un modello HTML frammisto con i frammenti di codice c#. Il simbolo @, viene utilizzato per indicare il parser Razor in cui si verifica una transizione tra il contenuto HTML statico e un frammento di codice. Qualsiasi esempio di testo il simbolo @, viene analizzato in base alle regole della sintassi del linguaggio c#. Gli elementi individuati durante l'analisi di testo vengono concatenati alla classe form compilata in modo dinamico in c# che viene compilato in tempo reale tramite .NET Compiler Platform ("Roslyn"). L'esecuzione di c# classe solo accumula il testo HTML nel flusso di risposte, combinazione di contenuti statici e calcolato in modo dinamico. Al termine, l'espressività del linguaggio Razor riguarda l'espressività delle HTML5.

Con Razor, il team di ASP.NET ha inoltre introdotto un elemento noto come helper HTML. Un helper HTML è una sorta di piccole dimensioni factory HTML che ottiene alcuni dati di input e genera solo il codice HTML desiderato. Tuttavia, gli helper HTML mai-acquisita tramite gli sviluppatori, in modo migliore strumento è stato aggiunto in ASP.NET Core: gli helper di tag. Gli helper di tag riprodurre lo stesso ruolo di helper HTML, funzionano come factory HTML, ma forniscono una sintassi più concisa e naturale. In particolare, è necessario che il codice c# per bloccare gli helper di tag con il codice del modello Razor. In alternativa, vengano visualizzate come elementi di sintassi HTML estesa. Di seguito è riportato un esempio di un helper tag:

<environment names="Development">
  <script src="~/content/scripts/yourapp.dev.js" />
</environment>
<environment names="Staging, Production">
  <script src="~/content/scripts/yourapp.min.js" 
    asp-append-version="true" />
</environment>

L'elemento di markup di ambiente non viene generato alla lettera al browser. In alternativa, tutto il relativo sottoalbero è sul lato server analizzato da un componente helper di tag che è in grado di leggere gli attributi e controllare e modificare la struttura HTML corrente. In questo esempio, l'helper di tag responsabile per l'elemento dell'ambiente corrispondente all'ambiente corrente di ASP.NET Core per il contenuto dell'attributo di nomi, quindi genera solo gli elementi di script che si applicano. Inoltre, l'elemento script viene elaborato da un altro helper di tag che controlla la struttura ad albero per un attributo personalizzato asp-Aggiungi-versione. Se viene trovato, l'URL effettivo in corso la generazione viene aggiunto con un timestamp per garantire che la risorsa collegata mai memorizzata nella cache.

Gli helper di tag sono classi c# tradizionalmente ereditata da una classe base o in modo dichiarativo associato agli attributi e degli elementi di markup. Ogni file Razor che intende utilizzare gli helper di tag deve dichiarare mediante la direttiva @addTagHelper. La direttiva viene semplicemente registrata classi helper di tag da un determinato assembly .NET Core. La direttiva @addTagHelper può risultare in singoli file Razor ma di solito passa nel file viewimports. cshtml e si applica globalmente per tutte le viste:

@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

Attributi ed elementi riconosciuti come gli helper di tag vengono evidenziati anche in Visual Studio con un colore specifico. ASP.NET Core viene fornito con un elenco completo degli helper di tag predefiniti che possono essere raggruppati in categorie alcuni. Alcuni influiscono su determinati elementi HTML è possibile avere in un modello Razor, ad esempio form, input, textarea, etichetta e selezionare. Alcuni helper esiste invece per semplificare e automatizzare la visualizzazione dei messaggi di convalida all'interno di moduli. Condividono tutti gli helper di tag predefiniti asp-* prefisso del nome. Altre informazioni sono reperibile in bit.ly/2w3BSS2.

Gli helper di tag aiuta a mantenere il codice sorgente Razor piuttosto leggibile e conciso. Alla luce di ciò, non vi sarà alcun motivo per evitare l'utilizzo di helper. In generale, è consigliabile l'utilizzo di helper di tag per automatizzare la scrittura di complessi e ripetitivi blocchi di codice, anziché creare qualsiasi elemento, ad esempio un linguaggio specifico di visualizzazione. Più utilizzare gli helper di tag, infatti, più unità manualmente lontano da HTML semplice e più costosi Esegui il rendering delle visualizzazioni HTML. Gli helper di tag sono una parte della tecnologia interessante, ma rappresentano un compromesso tra l'espressività e il costo di rendering lato server. Generale delle prestazioni, è inoltre importante ricordare che gli helper di tag non modificano la sintassi generale di markup in modo semplice, è possibile aprire un file Razor gli helper di tag in qualsiasi editor HTML senza incorrere in problemi di analisi. Lo stesso vale difficilmente gli helper HTML.

Visualizza i componenti

Tecnicamente, i componenti di visualizzazione sono componenti autonomi che includono la logica e visualizzazione. In ASP.NET Core, sostituiscono le azioni figlio, che non erano disponibili in classico ASP.NET MVC 5. Fare riferimento a viste componenti nei file Razor tramite c# bloccano e li passi i dati di input che ha richiesto:

@await Component.InvokeAsync("LatestNews", new { count = 4 })

Internamente, il componente di visualizzazione verrà eseguito una propria logica, elaborare i dati che è passato e restituire una visualizzazione pronto per il rendering. Non sono presenti componenti di visualizzazione predefinita in ASP.NET Core, vale a dire che verrà creati in una base di applicazione strict. La riga di codice precedente viene presentato un componente di visualizzazione LatestNews che è un blocco di markup è concettualmente simile alle visualizzazioni parziali nel pacchetto. La differenza tra una visualizzazione parziale e un componente di visualizzazione è l'implementazione interna. Una visualizzazione parziale è un modello semplice Razor facoltativamente riceve i dati di input e di incorporarli che nel modello HTML di cui viene eseguita. Una visualizzazione parziale non deve avere alcun comportamento propri, ad eccezione di formattazione e per il rendering.

Un componente di visualizzazione è una forma più sofisticata di una visualizzazione parziale. Facoltativamente, un componente di visualizzazione riceve i parametri di input normali che viene in genere utilizzato per recuperare ed elaborare i dati. Una volta disponibile, dati viene incorporati in un modello incorporato Razor, molto il comportamento di una visualizzazione parziale. Tuttavia, un componente di visualizzazione è più veloce nell'implementazione perché non passa attraverso il controller pipe inline le azioni figlio modo. Ciò significa che è presente alcuna associazione di modelli e nessun filtro azione.

In generale, Visualizza i componenti possono essere utilizzati noble di aiutare a componentize la visualizzazione in modo che risulti dalla composizione dei widget distinti e resi autonomo. Questo punto è un arma a doppio taglio. Con la visualizzazione di suddividere in componenti indipendenti e distinti può sembrare un modo pratico per organizzare il lavoro e rendendoli più parallela con più sviluppatori occuperà delle varie parti. Tuttavia, Visualizza i componenti non velocizzare le operazioni in tutti i casi. Tutto dipende ciascun componente cosa internamente. Quando si parla di componenti di visualizzazione e il modello di composizione UI sotto la visione, vengono spesso presentati con l'architettura di sistemi di grandi dimensioni orientata ai servizi, ad esempio, e che sia assolutamente corretto.

Tuttavia, quando si utilizza ciecamente visualizzazione componenti e il criterio, nel contesto di un qualsiasi sistema compatto, si rischierebbe di con la logica di query notevolmente ottimizzato. Ogni componente potrebbe eseguire query per i propri dati, generazione di ripetizione di query e il traffico del database non necessari. Visualizza i componenti possono essere utilizzati in questo scenario, ma è necessario considerare la memorizzazione nella cache i livelli per evitare risultati errati.

Passaggio di dati a viste

Esistono tre modi diversi, non esclusiva per passare dati a una visualizzazione Razor (oltre a DI tramite il @ inserire direttiva). È possibile utilizzare uno dei due dizionari predefiniti, ovvero ViewData o ViewBag, oppure è possibile utilizzare le classi di modello di visualizzazione fortemente tipizzata. Non esiste alcuna differenza tra questi approcci da un punto di vista funzionale puramente e anche dal punto di vista delle prestazioni è trascurabile la differenza.

Dal punto di vista di progettazione, tuttavia, è consigliabile utilizzare l'approccio di modello di visualizzazione singolo canale. Qualsiasi visualizzazione Razor deve avere una singola origine dei dati e che è l'oggetto modello di visualizzazione. Questo approccio richiede che prestare particolare attenzione alla progettazione della classe di base per i modelli di visualizzazione e di evitare di utilizzare dizionari e anche il @ inserire direttiva.

Tenere presente che questo approccio sembra strict, ma che derivino dall'esperienza. Può essere pericolosa, chiamata anche Now nella visualizzazione come inserisce i dati nella vista che potrebbe non essere sufficientemente astratta per l'applicazione. Now indica l'ora del server, non l'ora dell'applicazione. Si tratta di un problema per qualsiasi applicazione che dipende da ora del giorno per le relative operazioni. Per evitare questi tipi di trap, riesaminare la progettazione delle classi del modello di visualizzazione per prevedere i dati comuni, che è necessario che in tutte le visualizzazioni. Inoltre, assicurarsi di passare sempre i dati, ovvero tutti i dati, ovvero alle viste tramite il modello, evitando dizionari e DI quanto possibile. Sebbene sia più veloce usare dizionari e DI, non sarà più veloce in un secondo momento quando è necessario effettuare il refactoring di alcune funzionalità del dominio in un'applicazione di grandi dimensioni. SEN nelle viste è un'informazione interessante della tecnologia, ma deve essere utilizzata con oltre un livello di dettaglio del salt.

Conclusioni

Le visualizzazioni sono alla base delle applicazioni Web. In ASP.NET di base, le visualizzazioni sono il risultato dell'elaborazione di un file di modello, in genere un file di modello Razor, che è confuse con i dati forniti da un chiamante che la maggior parte è spesso un metodo del controller. In questo articolo, si tenta di confrontare i diversi approcci disponibili per creare visualizzazioni e passare dati. La maggior parte della documentazione di ASP.NET Core evidenzia il ruolo degli helper di tag e visualizza i componenti e persino pagine Razor e DI, nelle visualizzazioni. Anche se queste sono tutte le risorse interessanti, è importante evitare di utilizzarle ciecamente, presentano svantaggi naturali che possono produrre alcuni risultati errati se non si presta attenzione a come.

Dino Esposito* è l'autore di "Microsoft .NET: Architettura delle applicazioni per l'azienda"(Microsoft Press, 2014) e"Programmazione ASP.NET Core"(Microsoft Press, 2018). Un autore Pluralsight e developer sostenere in JetBrains Esposito condivide la sua visione del software su Twitter: @despos.*

Grazie per il seguente esperto tecnico di Microsoft per la revisione dell'articolo: Steve Smith

Viene illustrato in questo articolo nel forum di MSDN Magazine