La sintassi Razor offre un vantaggio convincente nel markup dell'interfaccia utente?

Noto che Scott Guthrie sta iniziando a menzionare Razor un bel po ' sul suo blog, ma non sono così sicuro che sia adatto al mio stile.

Certo, è uno stile abbastanza sconosciuto per qualcuno che è abbastanza abituato a un tipo "standard" di markup ASP.Net (segnaposto dei contenuti e codice inline), ma mi sembra che ci siano molte pagine aggiuntive da gestire e un markup meno chiaro per me.

Quali sono i sentimenti degli altri al riguardo? È qualcosa che ritieni debba essere seriamente considerato quando impalcature nuove pagine MVC o sta solo cercando di risolvere un problema che non esiste?

[Dichiarazione di non responsabilità: sono uno degli sviluppatori Microsoft su MVC e Razor, quindi potrei essere un po 'di parte :)]

Abbiamo progettato Razor per essere un linguaggio conciso di modelli che utilizza solo la quantità minima necessaria di caratteri di controllo. Direi che gran parte delle tue opinioni può essere espressa con meno caratteri rispetto allo stesso codice utilizzando la sintassi "tradizionale" di WebForms.

Ad esempio il seguente frammento di codice nella sintassi ASPX:

<% if(someCondition) { %>
  <ol>
  <% foreach(var item in Model) { %>
     <li><%: item.ToString() %></li>
  <% } %>
  </ol>
<% } %>

Può essere espresso come segue in Razor:

@if(someCondition) {
   <ol>
   @foreach(var item in Model) {
      <li>@item.ToString()</li>
   }
   </ol>
}

Mentre la versione ASPX ha 21 caratteri di transizione (il <%e %>), la versione Razor ne ha solo tre ( @)

Direi che i vantaggi di Razor sono i seguenti:

1. Sintassi concisa, che è molto simile al modo in cui scrivi codice C # normale (controlla il seguente post di blog recente di Phil Haack che confronta Asxp con la sintassi Razor: http://haacked.com/archive/2011/01/06/razor- sintassi-riferimento rapido.aspx )
2. Codifica HTML automatica dell'output (che ti aiuta a proteggerti dagli attacchi di iniezione HTML)
3. Convalida integrata (ma non al 100%) del markup che ti aiuta a evitare tag sbilanciati

Anche i concetti relativi alla pagina vengono mappati facilmente da ciò che hai in ASPX

• Come puoi vedere, il codice inline è ancora consentito
• Le sezioni (che possono essere facoltative) sono equivalenti ai segnaposto di contenuto
• Pagine di layout anziché pagine mastro
• I concetti di visualizzazione completa e parziale sono gli stessi
• @functions { ... } blocchi invece di <script runat="server"> ... </script>

Inoltre Razor ha una serie di concetti utili che direi migliori di quelli disponibili in ASPX:

• @helper funzioni per la creazione davvero facile di funzioni che emettono markup
• @modelparola chiave per specificare il tipo di modello della vista senza dover scrivere una <%@ Page ...direttiva con il nome completo della classe

Mi piacerebbe pensare che abbiamo affrontato un problema reale, che è quello di consentire di scrivere più facilmente visualizzazioni concise e conformi agli standard, fornendo allo stesso tempo i modi per eseguire il refactoring del codice comune.

Ovviamente, non tutti preferiranno la sintassi, motivo per cui supportiamo anche completamente il motore di visualizzazione ASPX. Inoltre puoi controllare Spark e NHaml, che sono due motori di visualizzazione di terze parti che godono di un significativo seguito dalla community. Il seguente post del blog ha un buon confronto tra le diverse offerte: http://blogs.msdn.com/b/coding4fun/archive/2010/10/04/10070953.aspx

Personalmente apprezzo molto la riduzione del numero di caratteri di escape utilizzati. L'utilizzo <% %>diventa molto noioso rispetto a @{}e non è così sintatticamente attraente.

Inoltre, la scrittura di un'intera definizione per il codice dietro e la pagina è semplificata in una singola @model model.

Come notato anche da marcind, anche non doverlo sempre includere runat=serverè molto bello.

Nel complesso, apprezzo molto l'utilizzo del motore Razor e trovo che non solo mi renda le cose più facili da sviluppare, ma renda anche il codice più facile da leggere.