Solución:
Recientemente, lanzamos una aplicación de tamaño bastante decente que usa Razor Pages para el front-end y controladores MVC para la API para los componentes del lado del cliente. Mi experiencia ha sido esta:
El paradigma de las páginas funciona bien cuando su contenido está estructurado en torno a la idea de “páginas” reales en el sitio. Piense en cosas como Contáctenos o Acerca de o incluso una página de Inicio de sesión. Claro, eso se podría hacer a través de MVC, pero MVC es realmente innecesario. Bastará con una simple página. Deje los controladores para cosas más relacionadas con el controlador, como un catálogo de productos o una base de datos de usuarios.
Si su arquitectura MVC gira en gran medida en torno a la estructura de su vista, las páginas de afeitar probablemente sean una buena opción. Todavía puede usar los bits MVC para cosas relacionadas con la API, pero el beneficio de las páginas es que su estructura de interfaz se vuelve más explícita y menos implícita (“basada en convenciones”) como con MVC, donde cada acción podría o no tener una vista que normalmente recibe el nombre de la acción.
Aunque Chris ha proporcionado una opinión clara sobre los marcos que se envían con una implementación estándar de ASP.NET Core. La gente también debe tener en cuenta que para que MS recomiende Razor Pages hay razones bastante más profundas para eso y han sido claras para mí, ya que soy un gran fanático de las Razor Pages.
Si hay algo más, excepto la simplicidad de una página, para preferir Razor Pages sobre Controladores / Vistas, específicamente, estoy interesado en el rendimiento de los dos marcos.
- Para responder a esto, parece que simplemente no ha hecho una aplicación realmente pesada en MVC si está haciendo esta pregunta. Los controladores se llenan de código, y podría ser realmente complicado, considerando que no todos los programadores están siguiendo buenas prácticas de programación (comentarios y administración de código adecuada) … Así que imagina un controlador con algunos métodos Page con lógica incorporada. . Bueno, el resultado es que fácilmente terminaría con un controlador que consta de más de 400 líneas de código que podrían dividirse fácilmente ya que se refiere a diferentes piezas (páginas o métodos). Entonces, ¿qué tal romper esas más de 300 líneas de código y separarlas en función de lo que hacen? Esta es toda la idea detrás de las páginas de la navaja. Solo coloca el código relacionado con una página específica en su propio modelo en lugar de mezclar código relacionado con 10 páginas en un archivo. Bueno, otros podrían argumentar que puede crear clases externas donde colocaría esta lógica para mantener limpios los controladores, pero ¿por qué hacer un esfuerzo adicional? y en segundo lugar, el rendimiento no debería ser un problema en absoluto. No creo que importe en este momento.
¿Es aceptable combinar Razor Pages y Controllers / Views al mismo tiempo?
- Bueno, MVC es el pináculo de WebAPI cuando se trata de .NET. Entonces, los dos se pueden mezclar en cualquier momento, en cualquier momento. Las páginas de Razor realmente se parecen a las “páginas reales”, pero son flexibles para adaptarse a cualquier cosa, ya sea un catálogo o lo que desee crear. cada página puede atender sus propias solicitudes GET, POST, etc., por lo que puede hacer lo que quiera con una página de maquinilla de afeitar. También debe quedar claro que el enrutamiento no es complicado con Razor Pages. Funciona tan flexible como en MVC …
He estado usando Razor Pages por un tiempo y noté que a pesar de la ventaja de la simplicidad de Razor Page, es un poco complicado cuando se trata de enrutamiento personalizado, estructuración de carpetas y modelo de vista complejo (el modelo de página parece estar desordenado).
- Prefiero no estar de acuerdo con esto. El enrutamiento es flexible con las páginas de Razor, simplemente no lo ha solucionado. Además, una página de maquinilla de afeitar puede crear una vista muy compleja porque puede enlazar tantos modelos de vista sin que se requiera ningún esfuerzo adicional. Con la regla de anotación
[BindProperties]o[BindProperty], puede importar tantos campos como desee en una vista … y recuerde que el enlace es bidireccional.
A menos que comience a trabajar con las páginas de Razor, escuchará muchas opiniones al respecto, algunas lo alejarán de usarlo, algunos como Chris le darán comentarios verdaderos. Pero mi consejo es que Razor Pages ha evolucionado y funciona mejor en cualquier aplicación de cualquier tamaño …
Espero que encuentre esto interesante de leer.
Familia .Net Core
Chris y Mosia dan buenas respuestas. Chris escribe
Suena como si simplemente no hubiera hecho una aplicación realmente pesada en MVC
No vi ninguna ventaja significativa de Razor Pages (RP) sobre MVC con controladores y vistas cuando porté Comenzar con ASP.NET Core MVC para Comenzar con Razor Pages en ASP.NET Core. No fue hasta que porté Comenzar con EF Core en una aplicación web ASP.NET MVC a Razor Pages con Entity Framework Core en ASP.NET Core que vi una ventaja de productividad significativa. MVC / EF no se acerca de ninguna manera a una aplicación de producción real, es mucho más simple. Sin embargo, tiene la complejidad suficiente para demostrar las ventajas de RP sobre MVC.
En las entrevistas con los clientes, la razón más común que escucho para seguir con los controladores y las vistas para la interfaz de usuario es que tienen una base de código de controlador / vista existente.
Las razones más comunes para preferir RP a MVC es evitar controladores inflados y una mejor integración entre páginas y vistas.
Razor Pages vs ASP.NET Core MVC y por qué elegir los tutoriales de MVC en lugar de Razor Pages proporciona más información y agrega enlaces a lo mejor MVC VS. RP contenido.
Muchos de los mejores comentarios en Por qué elegir los tutoriales de MVC en lugar de Razor Pages están ocultos. Busque oculto y seleccione Carga más…