asp.net-mvc - sintaxis - razor pages vs mvc

¿La sintaxis de Razor proporciona una ventaja convincente en el marcado de IU? (3)

Noté que Scott Guthrie está empezando a mencionar Razor un poco en su blog, pero no estoy tan seguro de que sea adecuado para mi estilo.

De acuerdo, es un estilo bastante desconocido para alguien que está bastante acostumbrado a un tipo de marcado ASP.Net "estándar" (titulares de lugar de contenido y código en línea), pero se siente como un montón de páginas adicionales para administrar y marcado menos claro para mí.

¿Cuáles son los sentimientos de otras personas al respecto? ¿Es algo que crees que se debe considerar seriamente al anclar nuevas páginas MVC o solo está tratando de resolver un problema que no existe?

Personalmente, realmente aprecio la reducción en la cantidad de caracteres de escape que se usan. Usar <% %> es muy tedioso cuando se compara con @{} y no es tan atractivo sintácticamente.

Además, escribir una definición completa para el código subyacente y la página se simplifica a un único @model model .

Como también señaló marcind, no tener que incluir siempre runat=server es muy bueno también.

En general, realmente aprecio usar el motor Razor y descubrir que no solo me facilita el desarrollo, sino que también hace que el código sea más fácil de leer.

Puedes probar este convertidor . Para obtener más información, consulte esta publicación de blog .

[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. Diría que gran parte de sus vistas se puede expresar con menos caracteres que el mismo código usando la sintaxis WebForms "tradicional".

Por ejemplo, el siguiente fragmento de código en la 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 (el <% 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 escribes el código C # normal (echa un vistazo a la siguiente publicación reciente de Phil Haack comparando Asxp con la sintaxis Razor: http://haacked.com/archive/2011/01/06/razor-syntax-quick-reference.aspx )
Codificación HTML automática de salida (lo que ayuda a protegerlo de los ataques de inyección html)
Validación integrada (aunque no al 100%) de su marcado que le ayuda a evitar etiquetas desequilibradas

Los conceptos relacionados con la página también se pueden mapear fácilmente de lo que tienes 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 vistas completas y parciales son los mismos
@functions { ... } lugar de <script runat="server"> ... </script>

Además, Razor tiene una serie de conceptos útiles que diría que son mejores que los disponibles en ASPX:

@helper funciona para la creación realmente fácil de funciones que emiten marcado
@model palabra clave para especificar el tipo de modelo de su vista sin tener que escribir una directiva <%@ Page ... con el nombre de clase completo

Me gustaría pensar que hemos abordado un problema real, que es permitirle escribir con mayor facilidad vistas concisas y que cumplan con los estándares, al mismo tiempo que le brindamos formas de refactorizar códigos comunes.

Por supuesto, no todos preferirán la sintaxis, y por eso también apoyamos totalmente el motor de vistas ASPX. Además, puede consultar Spark y NHaml, que son dos motores de vista 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