La syntaxe Razor offre-t-elle un avantage convaincant dans le balisage de l'interface utilisateur?

Je remarque que Scott Guthrie commence à mentionner un peu Razor sur son blog, mais je ne suis tout simplement pas sûr que ce soit un bon choix pour mon style.

Certes, c'est un style assez peu familier pour quelqu'un qui est assez habitué à une sorte de balisage ASP.Net "standard" (espaces réservés de contenu et code en ligne), mais cela me semble juste avoir beaucoup de pages supplémentaires à gérer et un balisage moins clair pour moi.

Quels sont les sentiments des autres à ce sujet? Est-ce quelque chose qui, selon vous, devrait être sérieusement pris en compte lors de l'échafaudage de nouvelles pages MVC ou essaie-t-il simplement de résoudre un problème qui n'existe pas?

[Avertissement: je suis l'un des développeurs Microsoft sur MVC et Razor, donc je suis peut-être un peu biaisé :)]

Nous avons conçu Razor pour être un langage de création de modèles concis qui n'utilise que le minimum nécessaire de caractères de contrôle. Je dirais que de grandes parties de vos vues peuvent être exprimées avec moins de caractères que le même code en utilisant la syntaxe "traditionnelle" des WebForms.

Par exemple, l'extrait de code suivant dans la syntaxe ASPX:

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

Peut être exprimé comme suit dans Razor:

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

Alors que la version ASPX a 21 caractères de transition (le <%et %>), la version Razor n'en a que trois ( @)

Je dirais que les avantages de Razor sont les suivants:

1. Syntaxe concise, qui est très similaire à la façon dont vous écrivez du code C # normal (consultez le récent article de blog suivant de Phil Haack comparant Asxp à la syntaxe Razor: http://haacked.com/archive/2011/01/06/razor- syntax-quick-reference.aspx )
2. Encodage HTML automatique de la sortie (qui vous protège des attaques par injection html)
3. Validation intégrée (mais pas à 100%) de votre balisage qui vous aide à éviter les balises déséquilibrées

Les concepts liés aux pages correspondent également facilement à ce que vous avez dans ASPX

• Comme vous pouvez le voir, le code en ligne est toujours autorisé
• Les sections (qui peuvent être facultatives) sont équivalentes aux espaces réservés de contenu
• Pages de mise en page au lieu de pages maîtres
• Les concepts de vues complètes et partielles sont les mêmes
• @functions { ... } blocs au lieu de <script runat="server"> ... </script>

De plus, Razor a un certain nombre de concepts utiles que je dirais meilleurs que ce qui est disponible dans ASPX:

• @helper fonctions pour une création très simple de fonctions qui émettent du balisage
• @modelmot-clé pour spécifier le type de modèle de votre vue sans avoir à écrire une <%@ Page ...directive avec le nom complet de la classe

Je voudrais penser que nous nous sommes attaqués à un vrai problème, qui est de vous permettre d'écrire plus facilement des vues concises et conformes aux standards tout en vous offrant en même temps des moyens de refactoriser le code commun.

Bien sûr, tout le monde ne préférera pas la syntaxe, c'est pourquoi nous prenons également entièrement en charge le moteur de visualisation ASPX. En outre, vous pouvez consulter Spark et NHaml, qui sont deux moteurs de visualisation tiers bénéficiant d'une communauté importante. Le billet de blog suivant présente une bonne comparaison des différentes offres: http://blogs.msdn.com/b/coding4fun/archive/2010/10/04/10070953.aspx

Personnellement, j'apprécie vraiment la réduction du nombre de caractères d'échappement utilisés. L'utilisation <% %>devient très fastidieuse par rapport à @{}et n'est pas aussi attrayante sur le plan syntaxique.

De plus, l'écriture d'une définition complète pour le code derrière et la page est simplifiée en une seule @model model.

Comme l'a également noté Marcind, ne pas avoir à toujours inclure runat=serverest très bien aussi.

Dans l'ensemble, j'apprécie vraiment l'utilisation du moteur Razor et je trouve que cela me facilite non seulement le développement, mais facilite également la lecture du code.