Razor Pages es una nueva característica introducida en Core.Net 2.0. Razor Page es una página que consta de diseño estándar (Ver) y una clase de back-end. En cierto sentido, se asemeja a Web Forms solo sin soporte estatal. La ventaja de esta solución es obvia: nos estamos deshaciendo de una capa innecesaria: el modelo de página (un modelo de datos en forma de, por ejemplo, Entity es por sí mismo). El backend de la página es tanto un controlador como un modelo, OOP classic, que encapsula datos y métodos para trabajar con ellos en un solo objeto. Al final, el modelo de página es solo una clase, no hay razón para que el controlador no pueda ser esta clase.
En otras palabras, Razor Pages es una solución web más sensata que MVC, ahora estamos tratando con el concepto tradicional y lógico de "página" y no con controladores y modelos diseminados por todo el proyecto. Pero dado que .NET se desarrollará en la dirección de Core.Net, es poco probable que Razor Page aparezca en el marco estándar, a pesar de que en los próximos años la mayoría de los proyectos permanecerán en .NET estándar. Sin embargo, es posible representar la funcionalidad de Razor Pages en un marco estándar.
La solución en realidad parece bastante trivial: debe agregar el siguiente diseño al controlador:
protected override void OnActionExecuting(ActionExecutingContext Context) { UpdateModel(this); }
El método OnActionExecuting es un evento del ciclo de vida que se llama antes de que se ejecute el método del controlador (es decir, el controlador de solicitud - Acción).
UpdateModel vincula directamente los parámetros de solicitud a las propiedades del modelo, en este caso, las propiedades de la clase de controlador.
Una conveniencia adicional: ahora no hay necesidad de aceptar explícitamente parámetros de tipo Modelo u otro. Aunque nada impide esto, si el parámetro es una identificación simple que se utilizará únicamente como una variable local, es necesario vincular los parámetros como propiedades del controlador, por ejemplo, si desea garantizar la persistencia de la página, que se discutirá más adelante.
Un simple ejemplo:
Tenemos el formulario de inicio de sesión habitual con dos campos.
No tiene sentido marcar; solo daré el código del controlador
public class AccountController : Controller { public string username{ get; set; } public string userpass{ get; set; } [HttpPost] public ActionResult OnLogin( ) {
Como puede ver, en el momento en que se desencadena el evento, los datos de entrada ya están vinculados y listos para usar.
Por supuesto, debemos tener en cuenta que ahora también necesitamos devolver como ActionResult el controlador, y en la plantilla escribir el nombre de la clase de controlador, como @Model AccountController.
Como consecuencia de esta solución, la tarea de mantener el estado de la página entre solicitudes también se simplifica. Supongamos que tiene una página con una tabla determinada, un filtro ordenado por columnas y paginación.
Hace clic en el filtro, el modelo vuelve a la vista y todo está bien, pero cuando hace clic en ordenar, el filtro se restablecerá naturalmente. El paginador reiniciará la clasificación y el filtro. En WebForms, el estado de la página se guardó automáticamente, en MVC debe aplicar varias decisiones engorrosas, por ejemplo, pegar todos los parámetros y conducirlos para cada solicitud, es decir, debe colgar todos los parámetros que vinieron antes del filtro en el enlace de clasificación.
Tales dificultades son una de las razones por las cuales SPA y otras locuras de JavaScript arrastran la lógica y los datos al navegador con los frenos resultantes del navegador (especialmente los dispositivos móviles), las páginas saltan y se sacuden para cada movimiento del mouse y aumentan la complejidad y el costo del trabajo, porque el backend es el mismo escriba de una forma u otra, empaque, descomprima los datos enviados a través de ajax, además de callbac hell, complicaciones de depuración, etc., y todo esto sin beneficio práctico para los visitantes del sitio que no les importa cómo Isana page.
La solución más lógica es guardar el estado de la página en la sesión. Dado que tenemos todos los parámetros necesarios a la mano en forma de propiedades del controlador, todo lo que debemos hacer es anular el método OnActionExecuted, que se llama después de procesar la solicitud, y empacar las propiedades necesarias en la sesión (la clave de la sesión obviamente debe apuntar al nombre del controlador).
protected override void OnActionExecuted (ActionExecutedContext Context) {
Los parámetros se restauran desde la sesión en el constructor del controlador o antes de llamar a UpdateModel (esto). Cuando llega una solicitud, por ejemplo, ordenaciones, los nuevos parámetros cambiarán y el resto permanecerá intacto y la vista se mostrará en la misma forma en que se envió.
Tal solución tiene una conveniencia más: por ejemplo, el usuario clasificó la tabla y decidió editar algún elemento abriendo otra página para esto. Naturalmente, quiere volver al estado de la lista que dejó, y dado que el estado de la página está en nuestra sesión, la página se restaurará automáticamente. No es necesario, como se hace a menudo, transferir toda la "bola de masa" de parámetros a la página de edición y viceversa. Si no es necesario guardar el estado entre páginas, el estado de la página puede almacenarse no en una sesión, sino en TempData.
Espero que estos "trucos de la vida", aunque parezcan triviales, sean útiles para los principiantes hasta que espíen en Internet soluciones más incómodas y engorrosas y decidan que no hay otras.