¡Prepárate porque este será un artículo largo pero informativo!
Con el lanzamiento del nuevo marco ASP.NET Core 2, Microsoft y su comunidad nos han brindado una nueva alternativa para el enfoque MVC (Modelo-Vista-Controlador). Microsoft lo ha llamado Razor Pages, y aunque es un enfoque un poco diferente, sigue siendo similar a MVC en algunos aspectos.
En este artículo, cubriremos los siguientes puntos importantes de ASP.NET Razor Pages.
Una página de Razor es muy similar al componente de vista de ASP.NET MVC. Tiene básicamente la misma sintaxis y funcionalidad que MVC.
La diferencia clave entre las páginas de Razor y MVC es que el modelo y el código del controlador también se incluyen dentro de la propia página de Razor.
En términos simples, es muy parecido al marco am MVVM (Model-View-View-Model). Proporciona enlace de datos bidireccional y una experiencia de desarrollo más simple con problemas aislados.
Aunque MVC funciona bien con aplicaciones web que tienen una gran cantidad de vistas dinámicas del servidor, aplicaciones de una sola página, API REST y llamadas AJAX, las Razor Pages son perfectas para páginas simples que son de solo lectura o que ingresan datos básicos.
Ahora, ASP.NET MVC ha sido extremadamente popular para el desarrollo de aplicaciones web y definitivamente tiene sus beneficios. De hecho, ASP.NET WebForms se diseñó específicamente como una solución MVVM en MVC.
Pero, el nuevo ASP.NET Core Razor Pages es la próxima evolución de ASP.NET WebForms.
Como la mayoría de ustedes probablemente saben, MVC significa Model-View-Controller. Es un patrón arquitectónico utilizado en el desarrollo de software para implementar UI (interfaces de usuario).
Si bien MVC es uno de los marcos más populares y está siendo utilizado por millones de desarrolladores web en todo el mundo, todavía tiene sus inconvenientes. Veamos los dos más importantes de ellos.
En ASP.NET MVC, hay montones de conceptos como TempData, RouteCollection, ViewData, Linq to SQL, Controller Action, Lambda Expression, Custom Route y HTML Helpers, todos los cuales vinculan el modelo, la vista y el controlador.
Ahora, no puede crear una aplicación web con ASP.NET MVC hasta que aprenda todos estos conceptos básicos. Además, incluso si los ha aprendido, aún enfrentará problemas de complejidad en ocasiones, especialmente cuando esté creando aplicaciones a gran escala.
En ASP.NET MVC, los desarrolladores web no pueden ignorar por completo la vista del modelo, incluso cuando ambos están separados. La razón es que cuando el modelo se cambia con frecuencia, las vistas de su aplicación pueden verse inundadas con solicitudes de actualización.
Las vistas son básicamente visualizaciones gráficas que tardan un tiempo en renderizarse según la complejidad de su aplicación. Y si su aplicación es compleja y el modelo ha cambiado mucho, es posible que la vista se retrase en las solicitudes de actualización. Por lo tanto, los desarrolladores deben dedicar más tiempo a solucionar esta situación, lo que genera costos más altos.
Hemos estado brindando servicios de desarrollo de ASP.NET MVC durante aproximadamente 10 años. De hecho, estamos certificados por Microsoft Gold Partner. Por lo tanto, en función de nuestro conocimiento, experiencia y pericia, hay dos beneficios principales de usar páginas de afeitar de ASP.NET Core en lugar de MVC.
Si alguna vez usó MVC para cualquier tipo de desarrollo web, entonces probablemente sepa cuánto tiempo lleva codificar una aplicación completa. Crear rutas dinámicas, nombrar las cosas correctamente y cientos de otras cosas consume mucho tiempo.
Razor Pages, por otro lado, está más organizado en comparación con MVC.
En Razor Pages, los archivos están básicamente más organizados. Tiene una Razor View y todo el código detrás de un archivo, de la misma manera que lo hacían los antiguos ASP.NET WebForms.
Nuevamente, si alguna vez ha usado un marco MVC antes, probablemente haya visto que hay algunas clases de controladores enormes que generalmente están llenas de muchas acciones diferentes. Estas clases son como un virus que crece más y más a medida que se agregan cosas nuevas.
Pero, en Razor Pages, cada página de la aplicación es independiente con su propia vista y código organizado en conjunto, lo que, como resultado, es menos complejo que el MVC.
En MVC, si agrega cosas nuevas, .NET Framework lo obligará a lanzar una nueva versión.
Por ejemplo, Microsoft lanzó el enrutamiento en MVC 4 y, más tarde, lanzó el enrutamiento de atributos para el cual nuevamente tuvieron que lanzar otro nuevo marco MVC 5.
En ASP.NET Core, por otro lado, todo se administra con el paquete NuGet, lo que significa que es más fácil que MVC actualizar el marco existente sin lanzar una nueva versión de .NET Framework cada vez que se agregan cosas nuevas.
Además, en .NET Core, cualquier comunidad puede publicar una actualización para la nueva versión del paquete NuGet y puede recibir los últimos cambios simplemente actualizando sus paquetes NuGet.
Explicamos en los puntos anteriores que construir una aplicación web usando ASP.NET Core Razor Pages es menos complejo que MVC. Aquí, lo demostraremos con acción.
Aquí hay una descripción general rápida de cómo MVC maneja las solicitudes.
Como puede ver, el enrutamiento es la clave de cómo MVC decide manejar las solicitudes. La configuración predeterminada para el enrutamiento es la combinación de nombres de acción y controlador.
Entonces, si solicita /staff/index, le enrutará la acción denominada Index en la clase StaffController.
Pero se puede personalizar o configurar para enrutar cualquier solicitud a cualquier controlador con un bloque de código.
Aquí hay una descripción general rápida de cómo Razor Pages maneja las solicitudes.
La diferencia entre los dos es que en Razor Pages, cuando realiza una solicitud, la configuración de enrutamiento predeterminada encontrará una Razor Page para esa solicitud específica en la carpeta Páginas.
Suponga que realiza una solicitud para /contacto/, luego ASP.NET Core buscará una página que tenga el mismo nombre que usó en la solicitud y lo dirigirá directamente a ella.
Eso significa que una solicitud a /contacto/ lo redirigirá a Contact.cshtml
Y para que cualquier archivo .cshtml se considere una página de Razor, debe colocarse en la carpeta Páginas y también contener @Page en su marcado.
De esta forma, Razor Page actuará como una acción de controlador. Ahora, comparando esto con MVC, la configuración de la ruta personalizada será menos compleja ya que no habrá codificación adicional involucrada.
Razor Pages parece un comienzo prometedor para el desarrollo de aplicaciones web modernas con menos complejidad en 2018. Y como la comparación ha demostrado que ofrece la ventaja de contener todo lo relacionado con una solicitud en particular en un solo lugar, mientras que en MVC requiere distribuir piezas por todo su aplicación como un rompecabezas gigante que luego tendrá que volver a armar con un esfuerzo adicional de codificación.
Si tienes alguna pregunta, les damos la bienvenida a todos en los comentarios, y si te ha gustado este artículo, muestra un poco de amor aplaudiéndolo.