O Razor Pages é um novo recurso introduzido no Core.Net 2.0. Página Razor é uma página que consiste em layout padrão (Exibir) e uma classe de back-end. De certa forma, ele se assemelha a formulários da Web apenas sem suporte de estado. A vantagem dessa solução é óbvia - estamos nos livrando de uma camada desnecessária - o modelo de página (um modelo de dados na forma de, por exemplo, Entidade é por si só). O backend da página é um controlador e um modelo - OOP classic - encapsulando dados e métodos de trabalho com eles em um objeto. No final, o modelo de página é apenas uma classe, não há razão para que o controlador não possa ser essa classe.
Em outras palavras, o Razor Pages é uma solução web mais sã do que o MVC, agora estamos lidando com o conceito tradicional e lógico de “página” e não com controladores e modelos espalhados por todo o projeto. Mas como o .NET se desenvolverá na direção do Core.Net, é improvável que o Razor Page apareça na estrutura padrão, apesar do fato de que nos próximos anos a maioria dos projetos permanecerá no .NET padrão. No entanto, é possível descrever a funcionalidade do Razor Pages em uma estrutura padrão.
A solução realmente parece bastante trivial - você precisa adicionar o seguinte design ao controlador:
protected override void OnActionExecuting(ActionExecutingContext Context) { UpdateModel(this); }
O método OnActionExecuting é um evento do ciclo de vida chamado antes da execução do método do controlador (ou seja, o manipulador de solicitações - Ação).
UpdateModel vincula diretamente os parâmetros de solicitação às propriedades do modelo - nesse caso, às propriedades da classe do controlador.
Uma conveniência adicional - agora não há necessidade de aceitar explicitamente parâmetros do tipo Model ou de qualquer outro. Embora nada impeça isso, se o parâmetro for um ID simples que será usado puramente como variável local, serão necessários parâmetros de ligação como propriedades do controlador, por exemplo, se você precisar garantir a persistência da página, que será discutida mais adiante.
Um exemplo simples:
Temos o formulário de login habitual com dois campos.
Não há sentido em marcar; apenas darei o código do controlador
public class AccountController : Controller { public string username{ get; set; } public string userpass{ get; set; } [HttpPost] public ActionResult OnLogin( ) {
Como você pode ver, no momento em que o evento é disparado, os dados de entrada já estão vinculados e prontos para uso.
Obviamente, devemos ter em mente que agora precisamos retornar como ActionResult o controlador também e, no modelo, registrar o nome da classe do controlador - como @Model AccountController.
Como conseqüência dessa solução, a tarefa de manter o estado da página entre solicitações também é simplificada. Digamos que você tenha uma página com uma determinada tabela, um filtro classificando por colunas e paginação.
Você clica no filtro, o modelo retorna à visualização e está tudo bem, mas quando você clica na classificação, o filtro é redefinido naturalmente. O paginador redefinirá a classificação e o filtro. No WebForms, o estado da página foi salvo automaticamente; no MVC, é necessário aplicar várias decisões complicadas, por exemplo, colar todos os parâmetros e conduzi-los para cada solicitação, ou seja, você precisa suspender todos os parâmetros anteriores a ele no filtro no link de classificação.
Essas dificuldades são uma das razões para o SPA e outra loucura de javascript ao arrastar a lógica e os dados para o navegador com os freios resultantes do navegador (especialmente dispositivos móveis), as páginas pulando e empurrando para cada movimento do mouse e aumentando a complexidade e o custo do trabalho - porque o back-end é o mesmo escreva de uma forma ou de outra, empacote os dados enviados via ajax, mais o inferno de callbac, complicações de depuração e assim por diante, e tudo isso sem benefícios práticos para os visitantes do site que não se importam com como Isana.
A solução mais lógica é salvar o estado da página na sessão. Como temos todos os parâmetros necessários em mãos na forma de propriedades do controlador, tudo o que é necessário é redefinir o método OnActionExecuted, chamado após o processamento da solicitação, e compactar as propriedades necessárias na sessão (a chave da sessão obviamente deve apontar para o nome do controlador).
protected override void OnActionExecuted (ActionExecutedContext Context) {
Os parâmetros são restaurados a partir da sessão no construtor do controlador ou antes de chamar UpdateModel (this). Quando uma solicitação chega, por exemplo, classificações, os novos parâmetros mudam e o restante permanece intocado e a exibição será exibida no mesmo formato em que foi enviada.
Essa solução tem mais uma conveniência - por exemplo, o usuário classificou a tabela e decidiu editar algum elemento abrindo outra página para isso. Naturalmente, ele deseja retornar ao estado da lista que deixou e, como o estado da página está em nossa sessão, a página será restaurada automaticamente. Não é necessário, como costuma ser feito, transferir todo o "bolinho" de parâmetros para a página de edição e vice-versa. Se não houver necessidade de salvar o estado entre as páginas, o estado da página poderá ser armazenado não em uma sessão, mas no TempData.
Espero que esses "hacks da vida", embora pareçam triviais, sejam úteis para iniciantes até que eles espionem a Internet em busca de soluções mais desconfortáveis e complicadas e decidam que não há outras.