[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:
- 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 )
- Encodage HTML automatique de la sortie (qui vous protège des attaques par injection html)
- 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