ASP.NET MVC Confronto motore di visualizzazione


339

Ho cercato su SO e Google una ripartizione dei vari motori di visualizzazione disponibili per ASP.NET MVC, ma non ho trovato molto più di semplici descrizioni di alto livello di cosa sia un motore di visualizzazione.

Non sto necessariamente cercando il "migliore" o il "più veloce", ma piuttosto alcuni confronti nel mondo reale dei vantaggi / svantaggi dei principali attori (ad esempio il WebFormViewEngine predefinito, i motori di visualizzazione MvcContrib, ecc.) Per varie situazioni. Penso che questo sarebbe davvero utile per determinare se il passaggio dal motore predefinito sarebbe vantaggioso per un determinato progetto o gruppo di sviluppo.

Qualcuno ha riscontrato un simile confronto?


43
Ironico del fatto che "non è costruttivo", ha comunque fornito molto valore a coloro che lo hanno visto quasi 45.000 volte. Peccato che SO stia limitando la propria utilità nonostante le esigenze della comunità. Dubito che @ Jeff Atwood si sentirebbe così.
mckamey,

Risposte:


430

Motori di visualizzazione ASP.NET MVC (Wiki della community)

Dal momento che un elenco completo non sembra esistere, iniziamo uno qui su SO. Questo può essere di grande valore per la comunità ASP.NET MVC se le persone aggiungono la loro esperienza (specialmente chiunque abbia contribuito a uno di questi). Qualsiasi implementazione IViewEngine(ad es. VirtualPathProviderViewEngine) È un gioco equo qui. Basta alfabetizzare i nuovi motori di visualizzazione (lasciando WebFormViewEngine e Razor in alto) e cercare di essere obiettivi nei confronti.


System.Web.Mvc.WebFormViewEngine

Obiettivi di progettazione:

Un motore di visualizzazione utilizzato per eseguire il rendering di una pagina di moduli Web alla risposta.

Professionisti:

  • onnipresente poiché fornito con ASP.NET MVC
  • esperienza familiare per gli sviluppatori ASP.NET
  • IntelliSense
  • può scegliere qualsiasi lingua con un provider CodeDom (ad es. C #, VB.NET, F #, Boo, Nemerle)
  • compilation su richiesta o viste precompilate

Contro:

  • l'utilizzo è confuso dall'esistenza di schemi "classici ASP.NET" che non si applicano più in MVC (ad es. ViewState PostBack)
  • può contribuire all'anti-pattern di "tag soup"
  • La sintassi del blocco di codice e la tipizzazione forte possono interferire
  • IntelliSense applica uno stile non sempre appropriato per i blocchi di codice in linea
  • può essere rumoroso quando si progettano modelli semplici

Esempio:

<%@ Control Inherits="System.Web.Mvc.ViewPage<IEnumerable<Product>>" %>
<% if(model.Any()) { %>
<ul>
    <% foreach(var p in model){%>
    <li><%=p.Name%></li>
    <%}%>
</ul>
<%}else{%>
    <p>No products available</p>
<%}%>

System.Web.Razor

Obiettivi di progettazione:

Professionisti:

  • Compatto, espressivo e fluido
  • Facile da imparare
  • Non è una nuova lingua
  • Ha un ottimo Intellisense
  • Unità testabile
  • Ubiquo, fornito con ASP.NET MVC

Contro:

  • Crea un problema leggermente diverso dal "tag soup" di cui sopra. Laddove i tag del server in realtà forniscono una struttura attorno al codice server e non server, Razor confonde HTML e codice server, rendendo difficile lo sviluppo di puro HTML o JS (vedi Con Esempio n. 1) mentre finisci per dover "sfuggire" a HTML e / o JavaScript tag in determinate condizioni molto comuni.
  • Scarsa incapsulamento + reuseabilità: è impraticabile chiamare un modello di rasoio come se fosse un metodo normale - in pratica il rasoio può chiamare il codice ma non viceversa, il che può incoraggiare la miscelazione di codice e presentazione.
  • La sintassi è molto orientata all'html; la generazione di contenuti non HTML può essere complicata. Nonostante ciò, il modello di dati del rasoio è essenzialmente solo una concatenazione di stringhe, quindi gli errori di sintassi e di annidamento non vengono rilevati né staticamente né dinamicamente, sebbene il design-time VS.NET aiuti a mitigarlo in qualche modo. A causa di ciò, la manutenibilità e la rifattabilità possono risentirne.
  • Nessuna API documentata , http://msdn.microsoft.com/en-us/library/system.web.razor.aspx

Con Esempio n. 1 (notare il posizionamento di "string [] ..."):

@{
    <h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
    foreach (var person in teamMembers)
    {
        <p>@person</p>
    }
}

Bellevue

Obiettivi di progettazione:

  • Rispetta l'HTML come linguaggio di prima classe anziché trattarlo come "solo testo".
  • Non scherzare con il mio HTML! Il codice di associazione dei dati (codice Bellevue) deve essere separato dall'HTML.
  • Applicare una rigorosa separazione vista modello

Brail

Obiettivi di progettazione:

Il motore di visualizzazione Brail è stato portato da MonoRail per funzionare con Microsoft ASP.NET MVC Framework. Per un'introduzione a Brail, consultare la documentazione sul sito Web del progetto Castle .

Professionisti:

  • modellato sulla "sintassi del pitone adatta al polso"
  • Visualizzazioni compilate su richiesta (ma nessuna precompilazione disponibile)

Contro:

  • progettato per essere scritto nella lingua Boo

Esempio:

<html>    
<head>        
<title>${title}</title>
</head>    
<body>        
     <p>The following items are in the list:</p>  
     <ul><%for element in list:    output "<li>${element}</li>"%></ul>
     <p>I hope that you would like Brail</p>    
</body>
</html>

Hasic

Hasic usa i letterali XML di VB.NET invece delle stringhe come la maggior parte degli altri motori di visualizzazione.

Professionisti:

  • Verifica in fase di compilazione di XML valido
  • Sintassi colorazione
  • Pieno intellisenso
  • Viste compilate
  • Estensibilità usando normali classi CLR, funzioni, ecc
  • Composibilità e manipolazione senza soluzione di continuità poiché si tratta del normale codice VB.NET
  • Unità testabile

Contro:

  • Prestazioni: crea l'intero DOM prima di inviarlo al client.

Esempio:

Protected Overrides Function Body() As XElement
    Return _
    <body>
        <h1>Hello, World</h1>
    </body>
End Function

NDjango

Obiettivi di progettazione:

NDjango è un'implementazione del Django Template Language sulla piattaforma .NET, usando il linguaggio F # .

Professionisti:


NHaml

Obiettivi di progettazione:

Porta .NET di Rails Haml view engine. Dal sito Web Haml :

Haml è un linguaggio di markup utilizzato per descrivere in modo chiaro e semplice l'XHTML di qualsiasi documento Web, senza l'uso del codice incorporato ... Haml evita la necessità di codificare esplicitamente l'XHTML nel modello, perché in realtà è una descrizione astratta dell'XHTML , con un po 'di codice per generare contenuti dinamici.

Professionisti:

  • struttura concisa (cioè SECCO)
  • ben rientrato
  • struttura chiara
  • C # Intellisense (per VS2008 senza ReSharper)

Contro:

  • un'astrazione da XHTML piuttosto che sfruttare la familiarità del markup
  • Nessun Intellisense per VS2010

Esempio:

@type=IEnumerable<Product>
- if(model.Any())
  %ul
    - foreach (var p in model)
      %li= p.Name
- else
  %p No products available

NVelocityViewEngine (MvcContrib)

Obiettivi di progettazione:

Un motore di visualizzazione basato su NVelocity che è una porta .NET del popolare progetto Java Velocity .

Professionisti:

  • facile da leggere / scrivere
  • codice di visualizzazione conciso

Contro:

  • numero limitato di metodi di supporto disponibili nella vista
  • non ha automaticamente l'integrazione di Visual Studio (IntelliSense, controllo delle visualizzazioni in fase di compilazione o refactoring)

Esempio:

#foreach ($p in $viewdata.Model)
#beforeall
    <ul>
#each
    <li>$p.Name</li>
#afterall
    </ul>
#nodata 
    <p>No products available</p>
#end

SharpTiles

Obiettivi di progettazione:

SharpTiles è una porta parziale di JSTL combinata con il concetto dietro il framework Tiles (a partire da Mile stone 1).

Professionisti:

  • familiare agli sviluppatori Java
  • Blocchi di codice in stile XML

Contro:

  • ...

Esempio:

<c:if test="${not fn:empty(Page.Tiles)}">
  <p class="note">
    <fmt:message key="page.tilesSupport"/>
  </p>
</c:if>

Spark View Engine

Obiettivi di progettazione:

L'idea è di consentire all'html di dominare il flusso e il codice per adattarsi perfettamente.

Professionisti:

  • Produce modelli più leggibili
  • C # Intellisense (per VS2008 senza ReSharper)
  • Plug-in SparkSense per VS2010 (funziona con ReSharper)
  • Fornisce una potente funzione di binding per sbarazzarsi di tutto il codice nelle visualizzazioni e consente di inventare facilmente i propri tag HTML

Contro:

  • Nessuna chiara separazione della logica del modello dal markup letterale (questo può essere mitigato dai prefissi dello spazio dei nomi)

Esempio:

<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
    <li each="var p in products">${p.Name}</li>
</ul>
<else>
    <p>No products available</p>
</else>

<Form style="background-color:olive;">
    <Label For="username" />
    <TextBox For="username" />
    <ValidationMessage For="username" Message="Please type a valid username." />
</Form>

StringTemplate Visualizza Engine MVC

Obiettivi di progettazione:

  • Leggero. Nessuna classe di pagina creata.
  • Veloce. I modelli vengono scritti nel flusso di output della risposta.
  • Copia cache. I modelli sono memorizzati nella cache, ma utilizzano un FileSystemWatcher per rilevare le modifiche ai file.
  • Dinamico. I modelli possono essere generati al volo nel codice.
  • Flessibile. I modelli possono essere nidificati a qualsiasi livello.
  • In linea con i principi MVC. Promuove la separazione di UI e Business Logic. Tutti i dati vengono creati in anticipo e passati al modello.

Professionisti:

  • familiare agli sviluppatori Java StringTemplate

Contro:

  • la sintassi del modello semplicistica può interferire con l'output previsto (ad esempio conflitto jQuery )

Wing Beats

Wing Beats è un DSL interno per la creazione di XHTML. Si basa su F # e include un motore di visualizzazione ASP.NET MVC, ma può anche essere utilizzato esclusivamente per la sua capacità di creare XHTML.

Professionisti:

  • Verifica in fase di compilazione di XML valido
  • Sintassi colorazione
  • Pieno intellisenso
  • Viste compilate
  • Estensibilità usando normali classi CLR, funzioni, ecc
  • Composibilità e manipolazione senza interruzioni dal momento che è un normale codice F #
  • Unità testabile

Contro:

  • In realtà non scrivi HTML ma codice che rappresenta HTML in un DSL.

XsltViewEngine (MvcContrib)

Obiettivi di progettazione:

Crea viste da XSLT familiare

Professionisti:

  • ampiamente onnipresente
  • linguaggio di template familiare per sviluppatori XML
  • basata su XML
  • time-tested
  • Sintassi ed errori di annidamento degli elementi possono essere rilevati staticamente.

Contro:

  • lo stile del linguaggio funzionale rende difficile il controllo del flusso
  • XSLT 2.0 non è (probabilmente?) Supportato. (XSLT 1.0 è molto meno pratico).


9
@ BrianLy: perché F # è compilato e funzionale, il che significa che è veloce, più interoperabile con il resto del runtime (almeno fino a c # 4) e idempotente. all'inizio abbiamo seguito la strada ironpython, ma non eravamo contenti dei risultati. per quanto riguarda la denominazione - siamo aperti ai suggerimenti :)
kolosy,

7
Voto negativo a causa della sezione Contro del Brail. Avere Boo come lingua non è certamente un truffatore.
Owen,

48
@Owen: Sì lo è. Devi guardare questo dal punto di vista di uno sviluppatore C #. Non vuoi imparare ancora un'altra lingua solo per usare un motore di template. (naturalmente se conosci già Boo, è bello, ma per la maggior parte degli sviluppatori C #, questo è un ulteriore ostacolo da superare)
Christian Klauser,

5
Il rasoio è lì. Dovrebbe essere aggiornato per alfabetizzare Razor.
mckamey,

3
Boo è un professionista, non un imbroglione. Sei già "fuori" da C #, più il modello può venire meglio è. C # non era pensato per essere usato in un contesto "modellante", è piuttosto espressivo ma non "amico del polso". D'altra parte, BOO è stato creato pensando a questo e in quanto tale si presta molto meglio ad essere utilizzato in un contesto esemplare.
Loudenvier,

17

La mia scelta attuale è Razor. È molto pulito e facile da leggere e mantiene le pagine di visualizzazione molto facili da mantenere. C'è anche il supporto intellisense che è davvero eccezionale. Anche se usato con gli aiutanti del web è anche molto potente.

Per fornire un semplice esempio:

@Model namespace.model
<!Doctype html>
<html>
<head>
<title>Test Razor</title>
</head>
<body>
<ul class="mainList">
@foreach(var x in ViewData.model)
{
<li>@x.PropertyName</li>
}
</ul>
</body>

E il gioco è fatto. È molto pulito e di facile lettura. Certo, questo è un semplice esempio ma anche su pagine e moduli complessi è ancora molto facile da leggere e capire.

Per quanto riguarda i contro? Bene finora (sono nuovo a questo) quando si usano alcuni degli helper per i moduli c'è una mancanza di supporto per l'aggiunta di un riferimento di classe CSS che è un po 'fastidioso.

Grazie Nathj07


1
Doh! Ho appena notato quanti anni ha questa discussione. Vabbè, forse qualcuno lo troverà e si dimostrerà comunque utile.
nathj07,

10

So che questo non risponde davvero alla tua domanda, ma diversi motori di visualizzazione hanno scopi diversi. La Spark View Engine , ad esempio, mira a liberare il vostro vista della "zuppa di tag", cercando di rendere tutto fluente e leggibile.

La tua scommessa migliore sarebbe solo guardare alcune implementazioni. Se sembra attraente per l'intento della tua soluzione, provalo. Puoi mescolare e abbinare i motori di visualizzazione in MVC, quindi non dovrebbe essere un problema se decidi di non andare con un motore specifico.


Grazie per la risposta. Stavo letteralmente iniziando quello che mi hai suggerito quando ho pensato "qualcuno ha già dovuto fare un riassunto". Spero in qualche aggregazione di questi tipi di obiettivi e difetti di progettazione. "The Spark View Engine ... ha lo scopo di liberare la tua visione di" tag soup ", cercando di rendere tutto fluido e leggibile." Ciò implica un motivo per costruirlo, nonché un difetto del motore di visualizzazione predefinito. Un altro proiettile nell'elenco.
mckamey,


5

Mi piace ndjango . È molto facile da usare e molto flessibile. Puoi estendere facilmente la funzionalità di visualizzazione con tag e filtri personalizzati. Penso che "fortemente legato a F #" sia piuttosto un vantaggio che uno svantaggio.


4

Penso che questo elenco dovrebbe includere anche esempi di ciascun motore di visualizzazione in modo che gli utenti possano avere un assaggio di ciascuno senza dover visitare tutti i siti Web.

Le immagini dicono più di mille parole e gli esempi di markup sono come schermate per i motori di visualizzazione :) Quindi eccone uno dal mio Spark View Engine preferito

<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
  <li each="var p in products">${p.Name}</li>
</ul>
<else>
  <p>No products available</p>
</else>

4
assomiglia troppo alla fusione fredda. Non sono un grande fan del mescolare il codice in markup in questo modo. Diventa difficile da mantenere.
Agile Jedi il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.