Razor / CSHTML – ¿Algún beneficio sobre lo que tenemos?

Cualquiera que esté utilizando la nueva función de páginas CSHTML y está descubriendo que prefiere esta nueva syntax del motor de vista sobre el motor de vista predeterminado MVC de ASP.NET existente o sobre formularios web, y si es así, ¿por qué? ¿Qué pasa con CSHTML le da una ventaja sobre MVC o formularios web, o viceversa?

Solo curiosidad por escuchar a la gente asumirlo.

Una de las ventajas es que las vistas de Razor se pueden procesar dentro de las pruebas unitarias, esto es algo que no era fácilmente posible con el renderizador ASP.Net anterior.

Desde el anuncio de ScottGu, esto se enumera como uno de los objectives de diseño:

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

Ex opinión del desarrollador de Microsoft

Trabajé en un equipo central para el sitio web de MSDN. Ahora, uso c # razor para sitios de comercio electrónico con mi equipo de progtwigción y nos enfocamos mucho en jQuery front end con back end c # razor pages y la base de datos de memoria de la entidad LINQ, por lo que las páginas tienen un tiempo de respuesta de 1 a 2 milisegundos incluso en nesteds para bucles con consultas y no hay caché de la página. No utilizamos MVC, simplemente ASP.NET con páginas de afeitar asignadas con el módulo de Reescritura de URL para IIS 7, sin páginas ASPX o ViewState o progtwigción de eventos del lado del servidor. No tiene las capas adicionales (innecesarias) que MVC coloca en las construcciones de código para la expresión regular impugnada. Menos es más para nosotros. Todo es magro y mezquino, pero le doy apoyo a MVC por su capacidad de prueba, pero eso es todo.

Las páginas de Razor no tienen un ciclo de vida de eventos como las páginas ASPX. Se acaba de renderizar como una página solicitada. C # es un gran lenguaje y Razor se sale de su camino muy bien para dejar que haga su trabajo. La escritura anónima con generics y linq hace la vida tan fácil con c # y páginas de afeitar. Usar las páginas de Razor te ayudará a pensar y codificar más ligero.

Uno de los inconvenientes de Razor y MVC es que no existe una persistencia similar a ViewState. Necesitaba implementar una solución para eso, así que terminé escribiendo un complemento jQuery para eso aquí -> http://www.jasonsebring.com/dumbFormState que es un complemento compatible con almacenamiento fuera de línea HTML 5 para el estado del formulario que está funcionando en todas las principales navegadores ahora Actualmente es solo para el estado del formulario, pero puede usar window.sessionStorage o window.localStorage de manera muy simple para almacenar cualquier tipo de estado en las devoluciones de datos o incluso en las solicitudes de página, simplemente me molesté en hacer que el guardado y el espacio de nombres se basen en la URL y el índice del formulario. No tienes que pensar en ello.

  1. Todo está codificado por defecto !!! Esto es bastante enorme.

  2. Los ayudantes declarativos pueden comstackrse para que no tenga que hacer nada especial para compartirlos. Creo que reemplazarán a los controles .ascx en cierta medida. Tienes que saltar a través de algunos aros para usar un control .ascx en otro proyecto.

  3. Usted puede hacer una sección requerida que es agradable.

El mayor beneficio es que el código es más conciso. El editor de VS también tendrá el soporte IntelliSense que algunos de los otros motores de visualización no tienen.

Los ayudantes HTML declarativos también se ven muy bien, ya que hacer ayudantes HTML dentro del código C # me recuerda a los controles personalizados en ASP.NET. Creo que tomaron una página de parciales pero con el código en línea.

Así que algunos beneficios definitivos sobre el motor de visualización asp.net.

Sin embargo, con un motor de vista como chispa:

Spark es aún más sucinto, puedes guardar los if y los bucles dentro de una etiqueta html. El marcado todavía se siente más natural para mí.

Puede codificar parciales exactamente cómo haría un ayudante declarativo, simplemente pasaría las variables al parcial y tendrá lo mismo. Esto ha existido con chispa durante bastante tiempo.