Solución:
De este artículo en Microsoft docs:
MVC: Al usar controladores y vistas, era común que las aplicaciones tuvieran muy
grandes controladores que funcionó con muchas dependencias y modelos de vista diferentes y devolvió muchas vistas diferentes. Esto resultó en mucha complejidad y a menudo resultó en controladores que no seguían el Single Responsibility Principle o Open/Closed Principles efectivamente.
Páginas de Razor aborda este problema encapsulando la lógica del lado del servidor para una “página” lógica determinada en una aplicación web. Una página de Razor que no tiene lógica del lado del 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 se denomina igual 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 de controlador, se ejecutan manejadores de modelos de página como “OnGet ()”, representando su página asociada por defecto.
Las páginas de Razor simplifican el proceso de creación de páginas individuales en una aplicación ASP.NET Core y, al mismo tiempo, 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.
Cuando usar MVC:
Si está creando API web, el patrón MVC tiene más sentido que intentar usar Razor Pages. Si su proyecto solo expondrá puntos finales de API web, idealmente debería comenzar desde la plantilla de proyecto de API web, pero de lo contrario es fácil agregar controladores y puntos finales API asociados a cualquier aplicación ASP.NET Core. También debe usar el enfoque MVC basado en vistas si está migrando una aplicación existente de ASP.NET MVC 5 o anterior a ASP.NET Core MVC y desea hacerlo con el menor 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 usando Razor Pages o vistas MVC, su aplicación tendrá
rendimiento similar e incluirá soporte para inyección de dependencia, filtros, enlace de modelos, validación, etc.
Actualizar: Algunas razones más por las que leí sobre este problema de github comentado por scott sauber:
Estamos usando Razor Pages para [complex] Portal de seguros médicos … Tenemos más de 60 páginas y puedo decir que para HTML renderizado por servidor, nunca volveré a MVC. Tampoco es solo para cosas simples. El dominio del seguro médico es intrínsecamente complejo y combina esto con el hecho de que es una aplicación de múltiples inquilinos (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 las diferentes compañías de seguros hacen las cosas de manera un poco diferente. .
¿Por qué usarlo?
-
Razor Pages es más seguro de forma predeterminada. Razor Pages le ofrece la validación AntiForgeryToken de forma predeterminada. Además, puede optar por las propiedades a las que desea vincular el modelo. [BindProperty] lo que limita su exposición a ataques de sobrepublicación.
-
Razor Pages tiene una mejor estructura de carpetas por defecto que escala mejor. En MVC, la estructura de carpetas predeterminada simplemente no se escala. Tener carpetas separadas para Vistas, Controladores y, a menudo, ViewModels cuando los tres están estrechamente acoplados entre sí es una gran PITA con la que trabajar. Terminas rebotando en las 3 carpetas y navegando un montón cada vez que necesitas agregar o cambiar una función. Es horrible. Es por eso que abogué por las carpetas de funciones. Con Razor Pages, su PageModel (Controller + ViewModel) está en la misma carpeta que su Vista. Simplemente puede presionar F7 para alternar entre ellos, lo que también es muy conveniente.
-
Conduce a un código más fácil de mantener 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 un redireccionamiento entre las dos). Esto hizo que navegar por el controlador para encontrar el código fuera muy difícil. Empeoró si también hubiera métodos privados en el Controlador, lo que se sumó a 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, es posible que tenga 8 acciones y algunas de sus dependencias en las que inyecta solo estaban relacionadas con una o dos acciones. Entonces, cuando la unidad prueba una sola acción, debe burlarse de ellas innecesariamente o pasar una null, los cuales se sienten asquerosos (esto se puede resolver un poco con el patrón Builder). Con Razor Pages, las dependencias en las 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 el anidamiento de carpetas sea mucho más fácil de lograr. Por ejemplo, todas nuestras páginas de administración de recursos humanos están bajo la
/Administratorcarpeta y todas las páginas de Empleados están bajo la/Employeecarpeta. Podemos autorizar una carpeta completa y decir que la persona debe ser un administrador para acceder a cualquier subcarpeta de/Administrator, que fue mucho más fácil de hacer que con varios controladores que componen las funciones de administrador.
Creo que eso es lo más importante.
Actualización 2:
Se trata de cierta complejidad del patrón MVC, no responde directamente a la pregunta pero puede ser útil: un gerente de ingeniería de Facebook, dijo (aquí) por su base de código “suficientemente” grande y su gran organización, “MVC se complicó realmente muy rápido”, concluyendo que MVC no escala. La complejidad del sistema se volvía 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 serio para los desarrolladores nuevos en una determinada base de código porque tenían miedo de tocar el código para no romper algo. El resultado fue MVC se estaba desmoronando para Facebook.
Razor Pages está optimizado para flujos de trabajo basados en páginas y se puede utilizar 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 (es) y ViewModel, todo en uno. La página, por supuesto, reemplaza a la Vista. Tampoco es necesario que tenga tantas carpetas como las que tendría en MVC, lo que simplifica aún más su proyecto.
De ASP.NET Core – Aplicaciones ASP.NET MVC más simples con Razor Pages, un artículo de MSDN de septiembre de 2017 de Steve Smith:
[Razor Pages] proveer
- una forma más sencilla de organizar el código dentro de las aplicaciones 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 forma 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 API, aún querrá usar controladores.
Edición de terceros: desventajas de la organización clásica de carpetas MVC
ASP.NET Core – Feature Slices for ASP.NET Core MVC, un artículo anterior de MSDN de septiembre de 2016, describe por qué la convención clásica de MVC para organizar vistas y controladores podría tener desventajas para proyectos más grandes. El artículo ofrece un ejemplo de cuatro conceptos de aplicación poco relacionados: Ninjas, Plantas, Piratas y Zombies. 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 configuración”, mientras oculta la configuración al desarrollador para hacer las cosas más rápidas. Pero tiene la desventaja de que todo será mixed de nuevo. No 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 MVC para REStful, es realmente más fácil usar las páginas de Razor. Si no es así, le recomendaría que utilice Core MVC.
En proyectos grandes, donde el modelo y el controlador están juntos en el mismo archivo, el mantenimiento será una pesadilla. Funciona bien para clases que tienen solo 2 propiedades, pero viola el principio de apertura y 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), simplemente extiéndalo usando el mismo patrón.
Si haces scroll puedes encontrar las interpretaciones de otros usuarios, tú también tienes la habilidad insertar el tuyo si lo deseas.