Quali sono i vantaggi dell'utilizzo di un motore di visualizzazione alternativo?

Question

Sto giocando con ASP.NET MVC e vedo che ci sono alcuni motori di visualizzazione alternativi disponibili come NHaml e Spark. La mia domanda è perché utilizzeresti un motore di visualizzazione alternativo? Non vedo un vantaggio di avere qualcosa di simile:

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

utilizzando il motore di visualizzazione Spark (doppiamente così da allora, e non ho usato Spark per verificare questo e potrebbe essere totalmente sbagliato, non lo faresti ottenere Intellisense dato che si sta passando il codice come una stringa) e:

<% if products.Any() { %> 
    <ul> 
     <% foreach (var p in products) { %> 
     <li><%= p.Name %></li> 
     <% } %> 
    </ul> 
<% } else { %> 
    <p>No products available</p> 
<% } %> 

utilizzando il built-in formato modello di ASP.NET MVC (anche se ammetto la parentesi graffa penzoloni è abbastanza brutto). Esiste una ragione legittima oltre a non considerare i tag "gator" (o parentesi graffe appese) da considerare l'utilizzo di un motore di visualizzazione alternativo? O è bello perché è qualcosa di nuovo?

Answer 1

cercare di renderlo un po' più complessa:.

<div if="orders.Any()" each="var order in orders"> 
    Here's your order #${orderIndex+1}: 
    <ul> 
    <li each="var p in order.Products"> 
     ${pIndex}: ${p.Name} 
     <span if="pIsLast"> (the end)</span> 
    </li> 
    </ul> 
</div> 

posso vedere il flusso qui. Posso effettivamente vedere HTML qui. Diamo un'occhiata:

<% if (orders.Any()) { %> 
    <% var orderIndex = 0; foreach (var order in orders") { %> 
    <div> 
    Here's your order #<%= (orderIndex+1) %> 
    <ul> 
     <% int pIndex = 0; foreach (var p in order.Products) 
     { bool pIsLast = pIndex == products.Count; %> 
     <li> 
      <%= pIndex %>: <%= p.Name %> 
      <% if (pIsLast) { %> 
       <span> (the end)</span> 
      <% } %> 
     </li> 
     <% ++ pIndex; } %> 
    </ul> 
    </div> 
    <% orderIndex++; } %> 
<% } %> 

Sono perso qui. C'è qualche HTML lì?

Per me, questo è il motivo principale. Naturalmente, Spark offre TON di funzionalità - macro (dove codifichi i tuoi Html.Helpers nella scintilla markup), esportazione PDF, ecc. - elencate da altri - ma come programmatore preferisco il codice pulito.

Come altro esempio, utilizzate spesso per (int i = 0; i < products.Count; i ++) {prodotto product = prodotti [i]; .... } questi giorni? Preferiresti foreach (prodotto var in prodotti) {}? Vorrei. Non solo perché è meno da digitare. Perché:

• esso esprime l'intento meglio
• si legge meglio
• nasconde ulteriori dettagli (come Count, .Length o Count(); o se è IEnumerable che si deve attraversare in un modo speciale) dalla mia mente stanca
• si riduce il numero di variabili che ingombrano il contesto (e la mia mente stanca)
• così posso concentrarmi sul problema, nulla va nel modo
• aiuta a evitare {} poiché non c'è bisogno di avere una variabile all'interno - la riduzione del numero di riga
• e quando si cambia la collezione da IList a matrice, non si cambia 50 loop tutto il luogo

e questo è una cosa semplice come foreach. Ogni motivo è semplice, ma riassumono in qualcosa di più grande. E questi motivi si applicano perfettamente a Spark. Ehi, sembra che io sia innamorata ;-)

Aggiornamento: ora, sai una cosa? Guarda la cronologia delle modifiche del mio post. Ho dovuto modificare il dannato codice ASP più volte solo perché mi mancavano alcuni bit qua e là. Io solo non vedo se è giusto o sbagliato. È completamente nascosto se ho lo span lì, o condizione al posto.

Aggiornamento: hm, ancora un altro modifica ... sposta ASP se/span all'interno li ...

Answer 2

Personalmente, non utilizzo i motori di visualizzazione alternativi, ma il loro appeal è quello delle viste più pulite. Se parli correntemente di Spark, quel primo esempio è molto più bello e più facile da leggere.

Tuttavia, preferisco avvolgere la logica come quella che hai dato in un metodo di supporto. Non devo imparare qualcosa di nuovo, tutti i miei colleghi possono capirlo, e le mie opinioni rimangono relativamente pulite. È una questione completamente soggettiva, e entrambi gli approcci vanno bene.

Questi motori di visualizzazione sono in gran parte un riporto da altri framework come RoR e Django. L'argomento di Django per il suo sistema di visualizzazione dei modelli è che le viste dovrebbero solo per la logica di visualizzazione.. Pertanto, se si limita ciò che è possibile nel motore di visualizzazione, si hanno meno opportunità di mescolare le responsabilità tra i controller e le viste.

Answer 3

Credo che la domanda è necessario porsi è "il motivo per cui si desidera modificare motori di vista" piuttosto che "Devo cambiare motori di vista"

Ho scelto scintilla perché volevo una vista più pulito alla ricerca e ho anche voluto usare per creare modelli per cose diverse dall'HTML. Attualmente lo uso per generare XML, JSON e modelli di email, quindi è diventato per me un motore di template e un motore di visualizzazione. Ciò è reso possibile perché consente di eseguire il rendering di viste su stringhe, il che non è (facilmente) disponibile nel motore di visualizzazione standard.

È anche importante notare che non è necessario utilizzare neanche un motore di visualizzazione singola. Puoi utilizzare più motori contemporaneamente in modo da poter utilizzare il motore di visualizzazione predefinito per i modelli HTML, ma passare alla scintilla per XML.

Complessivamente, se il motore di visualizzazione predefinito sta facendo tutto ciò che è necessario e ne sei soddisfatto, non mi preoccuperei affatto di passare, tuttavia se hai esigenze specifiche che non vengono soddisfatte dal motore di visualizzazione predefinito allora forse è il momento di guardare le alternative.

Answer 4

Alcuni dei vantaggi di Spark (quello che mi piace):

1. È possibile utilizzare una vista parziale come tag html. Esempio di utilizzo può essere tag per angoli arrotondati.
2. Non si ottiene "zuppa tag". Forse non vedi benefici in questo momento, ma se hai una visione enorme, è molto più leggibile.
3. Ottieni accesso fortemente digitato a ViewData ["..."].
4. È possibile rendere facilmente le viste alla stringa.
5. Applica automaticamente Html.Encode, aumentando la sicurezza dell'applicazione.

Quello che non mi piace:

1. ha problemi con Intellisense e ReSharper.
2. Impossibile utilizzare l'opzione Formato documento.

I Spark ha risolto questo problema, non vedrei motivo per utilizzare il motore di visualizzazione standard.

Answer 5

Direi che è più un'opzione che altro. E 'come decidere tra C# e Visual Basic, utilizzare ciò che si conosce meglio e quello che sarà più produttivo in