asp.net-mvc - una - razor view engine

Motor de vista ASP.NET MVC Razor

Question

Después de leer la entrada del blog de Scott Guthrie sobre el nuevo motor Razor view para ASP.NET MVC y leer esta question comparando los motores de vista disponibles.

Razor parece resolver la mayoría de los problemas con el motor de vista predeterminado. ¿Qué diferencias de características lo convertirían en una opción atractiva para usted como desarrollador? ¿Qué características le faltan para evitar que lo use?

Answer 1

Unidad comprobable: la implementación del nuevo motor de vista admitirá la capacidad de probar vistas de unidad (sin requerir un controlador o servidor web, y puede alojarse en cualquier proyecto de prueba de unidad, no se requiere un dominio de aplicación especial).

¡¡¡Al final!!! No puedo creer que tomó casi 8 años para que Microsoft finalmente traiga un motor de vista que lo soporte.

Answer 2

Además de la apariencia más limpia, la flexibilidad de las secciones de diseño se ve muy bien, y los ayudantes declarativos de HTML se ven muy útiles. Hasta el momento no veo ninguna desventaja en su uso, pero por supuesto tendremos que intentarlo en la práctica.

Answer 3

Hay mucho más para ver el motor, excepto el lenguaje de marcado. Pocas características de Spark que extrañaré:

• escribir extensiones html usando el mismo lenguaje de marcado, no C # (macros) - Veo que Razor también admite esto, espero que sea compatible con la anulación de método / parámetros;
• etiquetas personalizadas (escriba _Tag.spark para usar <Tag />);
• variables autogeneradas como varIsFirst, varIndex, etc;
• formas de expresión especial (? {} para atributos condicionales, $! {} para omitir errores, etc.);
• buen soporte para diseños maestros / parciales, incluida la capacidad de especificar en parte parcial que la parte del marcado debe representarse solo una vez en el maestro (por ejemplo, incluye el guión);
• aún puede tener el marcado WebForms, ideal para la compatibilidad y la actualización incremental;
• soporte para usar las comillas "" y "" dentro de la otra (extremadamente útil).

Me gusta la sintaxis de Spark para loops / ifs más: mezclar llaves HTML <> y C # {} no se ven muy bien, pero esa es una opinión puramente personal.

También hay características muy prometedoras en Razor, por ejemplo, plantillas en línea. Dado que el creador de Spark fue contratado por Microsoft, creo que existe la esperanza de que Razor sea un motor de visualización bien escrito y muy útil. Por supuesto, no volveré a escribir cientos de mis vistas de Spark con Razor (aunque reescribí docenas de mis vistas de WebForms con Spark). Pero seguro que le daré una mirada seria a Razor; solo lo he averiguado gracias a sus preguntas, y lo que veo ahora parece prometedor. No compite con WebForms, por supuesto (cualquier motor de vista es mejor que WebForms), pero parece una buena opción para un nuevo proyecto ASP.NET MVC, si aún no ha invertido en otro motor de visualización demasiado.

Answer 4

Obviamente, aún no lo he evaluado en la práctica, pero el hecho de que es más terser que el motor ASPX es la característica más convincente para inducir un cambio. Solo espero que también auto-formatee mejor. El hecho de que sea compatible con intellisense y se entregue con MVC lo convierte en una opción natural para comenzar nuevos proyectos. Voy a darle una buena oportunidad en un proyecto pequeño antes de hacer el cambio. Solo al leer el artículo, no vi nada que no pudiera hacer con él, lo que estoy haciendo actualmente con el motor ASPX.

Actualización: he estado usando Razor durante más de un año y nunca volvería al motor ASPX. La sintaxis parece muy natural y expresiva.

Answer 5

Para mí, hay tres razones convincentes:

1. Compilación : las vistas de Razor se pueden compilar en una DLL. Por fin conseguimos una adecuada reutilización en proyectos web .NET. Puedo tener un objeto comercial que sepa mostrarse sin tener ese código flotando como archivos .ascx en alguna parte del proyecto web.

2. Capacidad de prueba: a medida que se compila en una clase, puedo escribir una prueba unitaria y arrojar instancias de objetos falsos para ver si el HTML es correcto.

3. IntelliSense y la sintaxis de Terse son buenas pero no son las partes más importantes.

Answer 6

Razor usa Brackets, es decir, para cosas de foreach . Spark usa aquí etiquetas XML.

Por lo tanto, Spark es completamente compatible con el análisis y el análisis de un archivo de vista por procesador XML.

Mabye eso no es una gran cosa, pero muestra consistencia y extensibilidad.