[Descargo de responsabilidad: soy uno de los desarrolladores de Microsoft en MVC y Razor, por lo que podría ser un poco parcial :)]
Diseñamos Razor para que sea un lenguaje de plantillas conciso que utiliza solo la cantidad mínima necesaria de caracteres de control. Yo diría que gran parte de sus puntos de vista se pueden expresar con menos caracteres que el mismo código utilizando la sintaxis "tradicional" de WebForms.
Por ejemplo, el siguiente fragmento de código en sintaxis ASPX:
<% if(someCondition) { %>
<ol>
<% foreach(var item in Model) { %>
<li><%: item.ToString() %></li>
<% } %>
</ol>
<% } %>
Se puede expresar de la siguiente manera en Razor:
@if(someCondition) {
<ol>
@foreach(var item in Model) {
<li>@item.ToString()</li>
}
</ol>
}
Mientras que la versión ASPX tiene 21 caracteres de transición ( <%y %>), la versión Razor tiene solo tres ( @)
Diría que las ventajas de Razor son las siguientes:
- Sintaxis concisa, que es muy similar a la forma en que escribe código C # normal (consulte la siguiente publicación de blog reciente de Phil Haack que compara Asxp con la sintaxis de Razor: http://haacked.com/archive/2011/01/06/razor- syntax-quick-reference.aspx )
- Codificación HTML automática de la salida (que ayuda a protegerte de los ataques de inyección de HTML)
- Validación integrada (aunque no al 100%) de su marcado que lo ayuda a evitar etiquetas desequilibradas
Los conceptos relacionados con la página también se asignan fácilmente a lo que tiene en ASPX
- Como puede ver, el código en línea todavía está permitido
- Las secciones (que pueden ser opcionales) son equivalentes a los marcadores de posición de contenido
- Páginas de diseño en lugar de páginas maestras
- Los conceptos de vista total y parcial son los mismos
@functions { ... } bloques en lugar de <script runat="server"> ... </script>
Además, Razor tiene una serie de conceptos útiles que yo diría que son mejores que los que están disponibles en ASPX:
@helper funciones para la creación realmente fácil de funciones que emiten marcado@modelpalabra clave para especificar el tipo de modelo de su vista sin tener que escribir una <%@ Page ...directiva con el nombre completo de la clase
Me gustaría pensar que hemos abordado un problema real, que es permitirle escribir más fácilmente vistas concisas y que cumplan con los estándares y, al mismo tiempo, proporcionarle formas de refactorizar el código común.
Por supuesto, no todo el mundo preferirá la sintaxis, por lo que también apoyamos completamente el motor de visualización ASPX. Además, puede consultar Spark y NHaml, que son dos motores de visualización de terceros que disfrutan de un seguimiento significativo de la comunidad. La siguiente publicación de blog tiene una buena comparación de las diferentes ofertas: http://blogs.msdn.com/b/coding4fun/archive/2010/10/04/10070953.aspx