asp.net - que - razor pages vs mvc

¿Por qué Razor Pages es el enfoque recomendado para crear una interfaz de usuario web en Asp.net Core 2.0? (3)

Aprender cosas nuevas requiere una inversión de tiempo, espacio y energía. Actualmente estoy aprendiendo Asp.Net Core MVC 2.0. Este resumen de los tutoriales de ASP.NET Core dice:

Razor Pages es el enfoque recomendado para crear una interfaz de usuario web con ASP.NET Core 2.0.

Esta información me confundió al decidir si debo dejar de aprender Asp.net Core MVC y comenzar a aprender Asp.net Core Razor Pages.

¿Por qué Razor Pages es el enfoque recomendado para crear una interfaz de usuario web en Asp.net Core 2.0?

Cualquier dirección es bienvenida.

De la "Arquitectura de aplicaciones web modernas con el núcleo de asp.net" ( pdf aquí ):

MVC : al usar controladores y vistas, era común que las aplicaciones tuvieran controladores muy grandes que funcionaban con muchas dependencias y modelos de vista diferentes y que devolvían muchas vistas diferentes. Esto dio como resultado una gran complejidad y, a menudo, resultó en controladores que no siguieron el Single Responsibility Principle o los Single Responsibility Principle Open/Closed Principles efectiva.

Razor Pages resuelve este problema al encapsular la lógica del lado del servidor para una "página" lógica en una aplicación web. Una página de Razor que no tiene lógica de servidor puede consistir simplemente en un archivo de Razor (por ejemplo, "Index.cshtml"). Sin embargo, la mayoría de las páginas de Razor no triviales tendrán una clase de modelo de página asociada, que por convención recibe el mismo nombre que el archivo de Razor con una extensión ".cs" (por ejemplo, "Index.cshtml.cs"). Esta clase de modelo de página combina las responsabilidades de un Controlador y un Modelo de Vista. En lugar de manejar solicitudes con métodos de acción del controlador, se ejecutan controladores de modelos de página como "OnGet ()", que representan su página asociada de forma predeterminada.

Las páginas de Razor simplifican el proceso de creación de páginas individuales en una aplicación Core de ASP.NET, a la vez que proporcionan todas las características arquitectónicas de ASP.NET Core MVC. Son una buena opción predeterminada para la nueva funcionalidad basada en páginas (las páginas de Razor ofrecen un medio mucho más simple de crear características de aplicaciones basadas en páginas, como formularios que no son SPA).

Cuándo usar MVC :

Si estás creando API web, el patrón MVC tiene más sentido que tratar de usar Razor Pages. Si su proyecto solo expondrá los puntos finales de la API web, idealmente debería comenzar desde la plantilla de proyecto de la API web, pero de lo contrario, es fácil agregar controladores y puntos finales asociados de la API a cualquier aplicación Core de ASP.NET. También debe utilizar el enfoque de MVC basado en la vista si está migrando una aplicación existente de ASP.NET MVC 5 o anterior a ASP.NET Core MVC y desea hacerlo con el mínimo esfuerzo. Una vez que haya realizado la migración inicial, puede evaluar si tiene sentido adoptar Razor Pages para nuevas funciones o incluso como una migración al por mayor.

Nota: Ya sea que elija crear su aplicación web utilizando Razor Pages o MVC, su aplicación tendrá un rendimiento similar e incluirá soporte para inyección de dependencia, filtros, enlace de modelos, validación, etc.

Actualización: Algunas razones más que leí sobre este tema de github comentadas por scott sauber :

Estamos usando Razor Pages para un portal de seguro de salud para múltiples inquilinos donde los administradores de recursos humanos pueden CRUD en los datos de los empleados, ejecutar informes, cargar documentos, descargar documentos, estados de cuenta, etc. y los empleados que están asegurados pueden ver detalles sobre su seguro de salud , cambiarlo, descargar documentos, etc.
Tenemos más de 60 páginas y puedo decir que para el HTML renderizado del servidor , nunca volveré a MVC. Es simplemente un ajuste mejor para las aplicaciones HTML renderizadas en el servidor. Tampoco es solo para cosas simples. El dominio del seguro de salud es intrínsecamente complejo y combina esto con el hecho de que es una aplicación multiusuario (vendemos el producto a otras compañías de seguros), lo que agrega más complejidad, ya que la aplicación es altamente configurable ya que diferentes compañías de seguros hacen las cosas de manera un poco diferente .
¿Por qué usarlo?
Razor Pages es más seguro por defecto. Razor Pages le ofrece la validación de AntiForgeryToken de forma predeterminada. Además, usted opta por las propiedades que desea que sean vinculadas con el modelo a través de [BindProperty], lo que limita su exposición a ataques de sobre publicación.
Razor Pages tiene una mejor estructura de carpetas por defecto que se escala mejor. En MVC, la estructura de carpetas predeterminada simplemente no se escala. Tener una carpeta separada para Vistas, Controladores y, a menudo, Modelos de Vista cuando los tres están finalmente unidos entre sí es un gran PITA con el que trabajar. Usted termina rebotando en las 3 carpetas y navegando un grupo cada vez que necesita agregar o cambiar una función. Es horrible. Es por eso que abogué por las Carpetas de funciones. Con Razor Pages, su PageModel (Controlador + ViewModel) está en la misma carpeta que su Vista. Puedes presionar F7 para alternar entre ellos, lo que también es muy conveniente.
Conduce a un código más mantenible que se escala mejor. Con MVC fue muy fácil inflar un controlador con más de 10 acciones. A menudo, estas Acciones ni siquiera estaban relacionadas entre sí de ninguna manera (excepto tal vez una Redirección entre las dos). Esto hizo que navegar por el Controlador para encontrar el código sea muy difícil. Empeoró si también existían métodos privados en el Controlador, lo que aumentaría aún más la hinchazón del método. Con Razor Pages, es casi imposible inflar su modelo de página con métodos no relacionados con su página. Todo lo que pones en tu PageModel está relacionado con tu página.
La prueba unitaria es más fácil. Con un Controlador, puede tener 8 Acciones y algunas de las dependencias que inyectó solo se relacionaron con una o dos Acciones. Por lo tanto, cuando la unidad de prueba de una sola Acción necesita burlarse de ellos innecesariamente o pasar un nulo, ambos se sienten groseros (esto puede resolverse un poco con el patrón de Generador). Con Razor Pages, las dependencias que inyecta están 100% relacionadas con las acciones GET y POST con las que está trabajando. Simplemente se siente natural.
El enrutamiento es más fácil. De forma predeterminada, en Razor Pages, el enrutamiento solo coincide con la estructura de su carpeta. Esto hace que las carpetas de anidamiento sean mucho más fáciles de lograr. Por ejemplo, todas nuestras páginas de administración de recursos humanos se encuentran en la carpeta /Administrator y todas las páginas de empleados están en la carpeta /Employee . Podemos autorizar una carpeta completa y decir que la persona debe ser un Administrador para acceder a cualquier subcarpeta de /Administrator , lo cual fue mucho más fácil de hacer que con varios Controladores que conforman las funciones del Administrador.
Creo que eso es lo grande.

Actualización 2:

Esto tiene que ver con cierta complejidad del patrón MVC, no responde directamente a la pregunta, pero puede ser útil: un Gerente de Ingeniería en Facebook dijo ( here ) por su "suficiente" base de código grande y gran organización, "MVC se complicó realmente muy rápido" concluyendo que MVC no escala. La complejidad del sistema fue exponencial cada vez que intentaban agregar una nueva característica que hacía que el código fuera "frágil e impredecible". Esto se estaba convirtiendo en un problema grave para los desarrolladores nuevos en cierto código de base porque temían tocar el código para no romperlo. alguna cosa. El resultado fue que MVC se estaba desmoronando para Facebook .

Las páginas Razor están optimizadas para flujos de trabajo basados en páginas y se pueden usar en estos escenarios con menos partes móviles que los modelos MVC tradicionales. Esto se debe a que no necesita lidiar con controladores, acciones, rutas, modelos de vista y vistas (como lo haría normalmente). En cambio, su ruta está basada en convenciones, y su PageModel sirve como su Controlador, Acción (s) y ViewModel, todo en uno. La página, por supuesto, reemplaza a la vista. Tampoco tiene que tener tantas carpetas como lo haría en MVC, lo que simplifica aún más su proyecto.

Desde ASP.NET Core - Aplicaciones ASP.NET MVC más simples con Razor Pages , un artículo de MSDN de septiembre de 2017 por Steve Smith :

[Razor Pages] proporciona
una forma más sencilla de organizar el código dentro de las aplicaciones de ASP.NET Core, manteniendo la lógica de implementación y los modelos de vista más cerca del código de implementación de la vista.
También ofrecen una manera más sencilla de comenzar a desarrollar aplicaciones ASP.NET Core,

Ese artículo tiene más información sobre por qué usar Razor Pages sobre MVC para flujos de trabajo basados en páginas. Obviamente, para las APIs, todavía querrá usar Controladores.

Edición de terceros: desventajas de la organización clásica de carpetas MVC

ASP.NET Core: Feature Slices para ASP.NET Core MVC , un artículo más antiguo de MSDN de septiembre de 2016, describe por qué la convención MVC clásica para organizar vistas y controladores puede tener desventajas para proyectos más grandes. El artículo da un ejemplo de cuatro conceptos de aplicación vagamente relacionados: Ninjas, Plantas, Piratas y Zombis . El artículo describe una forma de estructurarlos fuera de la convención de carpetas predeterminada organizando los archivos en carpetas por función o área de responsabilidad.

Microsoft está volviendo al enfoque de WebForms para simplificar la estructura del proyecto confiando en el mantra "Convención sobre la configuración", mientras que oculta la configuración al desarrollador para hacer las cosas más rápido. Pero tiene la desventaja de que todo se mezclará de nuevo. No me parece un movimiento inteligente para organizar. ¡Pero hey! Algo nuevo debe llamar la atención del desarrollador hacia Microsoft.

Si su página usa una API web de MVC para el RESTO, es realmente más fácil usar solo las páginas de Razor. Si no, te recomiendo que uses Core MVC.

En grandes proyectos, donde el modelo y el controlador están juntos en el mismo archivo, el mantenimiento será una pesadilla. Funciona bien para clases que solo tienen 2 propiedades, pero viola el principio de cierre de OOP. Debe diseñar y usar una arquitectura que pueda crecer con el tiempo (Extensible) y aún así ser estable y lógica (sin reestructurar el proyecto), solo extiéndala utilizando el mismo patrón.