O time da ASP.NET MVC está nos estágios finais da finalização de um novo lançamento "Preview 4" que eles esperam entregar no final desta semana. O lançamento da Preview 3 focou na finalização de muitas APIs centrais e pontos de extensibilidade na ASP.NET MVC. Começando com a Preview 4 nesta semana você começará a ver mais e mais recursos de nível mais alto aparecendo, os quais são construídos em cima da fundação central e que adicionam boa produtividade.
Existem muitos novos recursos e capacidades nesta nova construção - de tal forma que eu decidi que precisarei de dois posts para cobrir todas. Este primeiro post irá cobrir os novos recursos de Caching, Tratamento de Erros e Segurança na Preview 4, como também algumas melhorias de teste que esta traz. Meu próximo post cobrirá os novos recursos AJAX que estão sendo adicionados com este novo lançamento.
Entendendo os Interceptadores de Filtro
Atributos de Filtro de Ação são capacidades de extensibilidade úteis na ASP.NET MVC que foram primeiramente introduzidos com o lançamento da "Preview 2". Estes permitem bons cenários de encapsulamento onde você pode facilmente empacotar e reusar funcionalidades de uma maneira declarativa e limpa.
A seguir está um exemplo de filtro super simples "ScottGuLog" que eu pude usar para fazer o log de detalhes sobre exceções que ocorreram durante a execução de uma requisição. Implementar um filtro customizado é fácil - simplesmente crie uma sub-classe que herda de "ActionFilterAttribute" e substitua os métodos apropriados para executar código antes e depois que um método de Ação no Controlador seja invocado, e/ou antes ou depois que um ActionResult seja processado para uma resposta.
Usar um filtro dentro de um Controlador ASP.NET MVC é fácil - simplesmente declare este como um atributo em um método de Ação, ou alternativamente na classe do próprio Controlador (neste caso este será aplicado para todos os métodos de Ação dentro do Controlador):
Acima você pode ver um exemplo de dois filtros sendo aplicados. Eu indiquei que eu quero que meu "ScottGuLog" seja aplicado no método de ação "About", e que eu quero que o filtro "HandleError" seja aplicado em todos os métodos de Ação no HomeController.
As previews anteriores da ASP.NET MVC permitiam esta extensibilidade de filtragem, mas não tinham filtro pré-construídos. A ASP.NET Preview 4 agora inclui vários filtros úteis para tratar cache de saída, tratamento de erro e cenários de segurança.
Filtro OutputCache
O filtro [OutputCache] provê uma maneira fácil de integrar ASP.NET MVC com os recursos de cache de saída da ASP.NET (com ASP.NET MVC Preview 3 você tinha que escrever código para obter este recurso).
Para experimentar, modifique o valor de "Message" dentro do método de ação "Index" do HomeController (criado pelo template de projeto do VS ASP.NET MVC) para mostrar a hora atual:
Quando você executar sua aplicação você verá que uma marcação de tempo se atualizará a cada atualização da página:
Nós podemos ativar o cache de saída para esta URL adicionando o atributo [OutputCache] em nosso método de ação. Nós iremos configurar este para fazer o cache da resposta por um período de 10 segundos usando a declaração a seguir:
Agora quando você clicar em atualizar na página você verá que a marcação do tempo somente será atualizada a cada 10 segundos. Isto acontece porque o método de ação será chamado uma única vez a cada 10 segundos - todas as requisições entre estes intervalos de tempo serão servidos fora do cache de saída da ASP.NET (significando que nenhum código necessita ser executado - o que torna o processo super rápido).
Além do suporte à duração de tempo, o atributo OutputCache também suporta as opções padrão do cache de saída da ASP.NET como (vary by params (parâmetros), headers (cabeçalhos), content encoding (codificação do conteúdo) e custom logic (lógica customizada)). Por exemplo, o exemplo a seguir salvaria diferentes versões da página presentes no cache dependendo do valor opcional de um parâmetro "PageIndex" presente em uma QueryString, e automaticamente produziria a versão correta dependendo do valor da querystring presente na URL de chegada:
Você também pode integrar com o recurso Database Cache Invalidation da ASP.NET - o qual permite que você automaticamente invalide o cache quando um banco de dados do qual a URL depende é modificado (dica: a melhor maneira de fazer isto é configurar a seção CacheProfile dentro de sua web.config e então apontar para esta no atributo OutputCache).
Filtro HandleError
O filtro [HandleError] provê um meio para declarativamente indicar em um Controlador ou método de Ação que uma resposta de erro amigável deve ser mostrada se um erro ocorrer durante o processamento de uma requisição ASP.NET MVC.
Para experimentar, adicione um novo "TestController" em um projeto e implemente um método de ação que lança uma exceção igual a seguir:
Por padrão quando você aponta seu browser para esta URL, este irá mostrar uma página de erro padrão da ASP.NET para usuários remotos (a menos que você tenha configurado uma seção <customErrors> no seu arquivo web.config):
Nós podemos mudar o HTLM do erro mostrado para que este seja mais amigável em uma mensagem para o usuário final adicionando para tanto um atributo [HandleError] em nosso Controlador ou em um método de Ação no nosso Controlador:
O filtro HandleError pegará todas as exceções (incluindo erros lançados quando templates de Visão forem processadas), e mostrará uma visão de Error customizada em resposta quando os errors ocorrerem. Por padrão este tenta localizar uma template de Visão no seu projeto chamada "Error" para gerar a resposta. Você pode colocar esta visão "Error" no mesmo diretório das visões específicas de outros Controladores (por exemplo: \Views\Test para o controlador TestController acima), ou dentro da pasta \Views\Shared (este buscará primeiramente por um controlador específico para a visão error, e então se não encontrar um, buscará na pasta compartilhada - a qual contém visões que são compartilhadas por todos os controladores).
O Visual Studio agora automaticamente adiciona um template de visão padrão "Error" para você dentro da pasta \Views\Shared quando você cria um novo projeto ASP.NET MVC começando com a Preview 4:
Quando nós adicionamos um atributo [HandleError] em nosso TestController, este irá por padrão mostrar aos usuários remotos uma página de erro HTML igual a seguir (note que este seleciona o template da master page (página principal) do projeto de forma que a mensagem de erro seja integrada dentro do site), Você pode obviamente entrar e customizar o template da visão de Error para mostrar qualquer HTML e/ou mensagens de erro mais amigáveis para os clientes/usuários - a seguir está o que você recebe por padrão:
Para ajudar os desenvolvedores, o template padrão da visão Error fornecida pelo template de novo projeto no Visual Studio é escrita para mostrar informações adicionais da pilha de comandos quando você está navegando na aplicação localmente:
Você pode desativar esta opção deletando o código do template da visão Error, ou configurando <customErrors> para desativado dentro do seu arquivo web.config.
Por padrão o filtro [HandleError] irá pegar e tratar todas as exceções que forem lançadas durante a requisição. Você pode alternativamente especificar os tipos de exceção que você está interessado em pegar, e especificar visões de erro customizadas especificando as propriedades "ExceptionType" e "View" nos atributos de [HandleError]:
No código acima eu estou escolhendo mostrar visões de erro customizadas para exceções do tipo SqlException e NullReferenceException. Todas as outras exceções usarão então o template de visão padrão "Error".
Filtro Authorize
O filtro [Authorize] provê um meio para declarativamente controlar a segurança do acesso em um Controlador ou método de Ação. Este permite que você indique se um usuário deve estar logado, e opcionalmente se ele deve ser um usuário específico ou se ele deve representar um papel de segurança específico para ter acesso ao site. O filtro trabalha com todos os tipos de autenticação (incluindo Windows como também as baseadas em Formulários de autenticação), e provê suporte para redirecionamento automático de usuários anônimos para um formulário de login se isso for necessário.
Para experimentar, adicione um filtro [Authorize] na ação "About" no HomeController criado por padrão com o Visual Studio:
Declarando um atributo [Authorize] igual acima indica que um usuário deve estar logado no site para requisitar a ação "About". Quando usuários não logados tentarem carregar a URL /Home/About, eles serão bloqueados e não conseguirão acessar a página. Se a aplicação web for configurada para usar a autenticação baseada no Windows, a ASP.NET irá automaticamente autenticar o usuário usando a identidade de login e se a tentativa for bem sucedida então o usuário terá permissão para prosseguir. Se a aplicação web for configurada para usar autenticação baseada em formulários, o atributo [Authorize] irá automaticamente redirecionar o usuário para uma página de login para autenticá-lo (e só depois ele terá acesso).
O atributo [Authorize] opcionalmente permite que você conceda acesso somente para usuários específicos e/ou cargos. Por exemplo, se eu quisesse limitar o acesso à ação "About" para somente eu e Bill Gates, eu poderia escrever:
Tipicamente para todas as aplicações (excluindo as triviais) você não irá querer que os nomes dos usuários sejam escritos dentro do código. Ao invés disso você usualmente quer um conceito de nível mais alto como "roles" (cargos) para definir permissões, e então mapear usuário para cargos separadamente (por exemplo: usando active directory ou um banco de dados para armazenar os mapeamentos). O atributo [Authorize] torna fácil controlar o acesso aos Controladores e Ações usando uma propriedade "Roles":
O atributo [Authorize] não depende de nenhuma identidade de usuário específico ou mecanismo de gerenciamento. Ao invés disso este funciona com o objeto "User" da ASP.NET - o qual é extensível e permite que qualquer sistema de identidade seja usado.
Classe AccountController
Eu mencionei acima que o atributo [Authorize] pode ser usado com qualquer autenticação ou sistema de gerenciamento de identidade de usuários. Você pode escrever ou usar qualquer UI de login customizada e/ou sistema de de gerenciamento de nomedeusuario/senha que você quiser com este.
Para ajudar você a começar, o template de projeto ASP.NET MVC no Visual Studio agora inclui uma "AccountController" pré-construída e associada com visões de login que implementa uma autenticação baseada em formulários para um sistema de associação de usuários com suporte para login, logout, registro de novos usuários e mudança de senha. Todas as templates de visão e UI podem ser facilmente customizadas independentemente da classe AccountController ou implementação:
A template Site.master agora inclui também UI no topo à direita da página que provê funcionalidades de login/logout. Quando você usar autenticação baseada em formulários você será perguntado sobre o login caso você ainda não esteja autenticado.
Uma mensagem de boas vindas será mostrada juntamente com o link de logout se você estiver autenticado no site:
Clicando no link de Login acima leva os usuários para uma tela de Login igual a seguir que eles podem usar para realizar a autenticação:
Novos usuários podem clicar no link de registro para criar novas contas:
Tratamento e exibição dos erros também são pré-configurados:
A classe AccountController que é adicionada em novos projetos usa a API de Associação pré-construída da ASP.NET para armazenar e gerenciar as credenciais dos usuários (o sistema de associação usa uma API baseada em provedores que permite que qualquer sistema de armazenamento secundário seja plugado; a ASP.NET inclui provedores pré-construídos para Active Directory e SQL Server). Se você não quer usar o sistema de Associação pré-construído você pode manter as mesmas assinaturas dos métodos de ação do controlador AccountController, templates de Visão, e a lógica para o ticket dos Formulário de Autenticação, bastando simplesmente substituir a lógica da conta do usuário dentro da classe AccountController. Para o próximo lançamento da ASP.NET MVC nós estamos planejando encapsular a lógica de interação entre AccountController e o sistema de identificação de usuários em uma interface - a qual tornará ainda mais fácil: plugar o seu próprio sistema de armazenamento de usuários (sem ter que implementar um provedor de associação por completo) como também realizar testes unitários mais facilmente na interface e o AccountController.
Nosso desejo é que isto forneça uma maneira prática para que as pessoas rapidamente comecem, permitindo que elas tenham um sistema completo de segurança que funcione a partir do momento da criação de um projeto.Testando TempData (Dados temporários)
Uma última melhoria a discutir neste primeiro post da preview 4 é sobre alguns aprimoramentos que estão sendo feitos na classe Controller que permite que você execute testes unitários mais facilmente na coleção TempData. A propriedade TempData permite a armazenagem de dados que você quer persistir para uma futura requisição proveniente de um usuário. Esta tem a semântica de somente durar para uma futura requisição (após a qual esta é removida). É tipicamente usada para cenários MVC onde você quer realizar um redirecionamento no lado do cliente para mudar a URL no browser, buscando com isso uma maneira simples de armazenar dados temporários.
Em previews anteriores da ASP.NET MVC você tinha que imitar objetos para testar a coleção TempData. Com a Preview 4 você não mais precisa imitar ou configurar nada. Você pode agora adicionar e verificar objetos dentro da coleção TempData do Controlador diretamente dentro de seus testes unitários (por exemplo: popular uma propriedade TempData de um Controlador antes de chamar seu método de ação, ou verificar se uma ação atualizou TempData após o retorno da ação). A semântica atual da armazenagem da coleção TempData está agora encapsulada dentro de uma propriedade TempDataProvider separada.
Conclusão
Esperançosamente o post acima provê uma visão rápida sobre alguns dos novos recursos e mudanças que estão chagando com a ASP.NET MVC Preview 4. Meu próximo post sobre a ASP.NET MVC Preview 4 cobrirá a nova funcionalidade AJAX que foi adicionada, e demonstrará como tirar vantagem desta.
Espero que ajude,
Scott
(Texto traduzido do post original por Leniel Macaferi.)