ASP
.NET MVC 3 - Sua majestade o Controlador
ASP
.NET MVC 3 - Sua majestade o Controlador
Apesar da referência explícita ao padrão Model-View-Controller no nome, a arquitetura ASP.NET MVC esta essencialmente centrada em um pilar : o controlador.
O controlador governa o processamento de um pedido e orquestra o back-end do sistema (por exemplo, camada de negócios, serviços, camada de acesso aos dados) para pegar os dados para a resposta.
Em seguida, o controlador empacota os dados brutos computados para a solicitação em uma resposta válida para o chamador.
Quando a resposta é uma view, o controlador baseia-se no módulo do motor view para combinar dados e modelos de view e gerar o HTML.
Qualquer pedido que passa pelo filtro de roteamento URL está mapeado para uma classe de controlador sendo servido pela execução de um determinado método na classe. Portanto, a classe controlador é o lugar onde você, como desenvolvedor, vai escrever o código necessário para atender a um pedido.
Em geral uma aplicação ASP .NET MVC é composta de diversos controladores mas você pode organizar a sua aplicação de forma a usar somente um controlador que contenha métodos para qualquer requisição possível.
Uma prática comum consiste em ter uma classe de controlador para cada objeto significativo que a sua aplicação manipula. Por exemplo, você pode ter uma classe ClienteController que cuida dos pedidos relacionados a consulta, exclusão, atualização e inserção de clientes.
Da mesma forma, você pode ter uma classe ProdutoController para lidar com os produtos, e assim por diante. Na maioria das vezes, esses objetos estão diretamente relacionados aos itens no menu principal da aplicação.
A cada solicitação uma nova instância da classe controlador selecionada é criada. Qualquer estado que você poderia adicionar à classe é vinculado ao mesmo tempo de vida da requisição. A classe controlador então deve ser capaz de recuperar os dados que necessita para trabalhar a partir do fluxo de solicitação HTTP e do contexto HTTP.
No ASP.NET MVC o controlador é isolado tanto da interface do usuário que gerou o pedido como do motor que produz a view para o navegador. Embora este tipo de isolamento da view seja bem-vindo, pois corrige um ponto fraco das aplicações Web Forms do ASP.NET, ele sozinho não garante que seu código será mais robusto de acordo com o princípio da separação de preocupações (SoC).
Esse modelo lhe dá um nível mínimo de separação da view e o resto é por sua conta. Tenha em mente que nada, nem mesmo o ASP.NET MVC, impede o uso de chamadas diretas ao ADO.NET e as consultas T-SQL diretamente da classe do controlador.
A classe do controlador não é a camada de acesso a dados do sistema e também não é a camada de negócios. Deve ser considerada, em vez disso, como a contrapartida MVC da classe code-behind de Web Forms, e como tal, ela pertence à camada de apresentação, não à camada de negócios.
Esta falta de estado característica do controlador e sua separação da view torna a classe controladora potencialmente fácil de testar. Porém a real testabilidade da classe controladora deverá ser medida contra a sua efetiva disposição em camadas.
Na implementação MVC do ASP .NET MVC os requisitos para uma classe ser considerada o controller são :
Uma classe controller contém métodos que são as conhecido como Actions.
Uma action é utilizada para processar uma requisição HTTP e ela pode conter ou não conter argumentos.
Para criar uma action é preciso definir o método como public sendo que o valor de retorno será uma instância de uma classe que deriva de ActionResult.
Quando o usuário faz uma requisição através do navegador, o ASP .NET MVC verifica na tabela de rotas, definido no arquivo Global.asax, e é o controller que irá receber a requisição.
O controller irá definir o método apropriado para processar a requisição e por padrão as URLs seguem a estrutura {NomeDoControlador}/{NomeDaAction}.
Após o controller receber a requisição e processá-la, ele devolve uma resposta para o usuário; e isso pode ser das seguintes formas:
No ASP .NET MVC temos uma classe apropriada para cada tipo de retorno que é derivada de ActionResult.
| Classe derivada de Action Result | Descrição | Exemplo |
| ViewResult | Retorna uma View | return View(); return View(“NomeDaView”, objeto- Model); |
| PartialViewResult | Retorna uma
partial View, que pode ser inserida em outra View.(UserControl) |
return
PartialView(); return PartialView(“Nome_Da_PartialView”, objetoModel); |
| RedirectResult | Redireciona para uma Url específica | return Redirect(“http://www.macoratti.net”); |
| RedirectToRouteResult | Redireciona para outra Action | return
RedirectToAction(“Outra_Action”,
“Outro_Controller”); return RedirectTo-Route(“Nome_Da_Rota”); |
| ContentResult | Retorna texto puro | return Content(“Texto”,“textoplano”); |
| JsonResult | Retorna um objeto no formato JSON | return Json(objeto); |
| JavaScriptResult | Retorna código Javascript que pode ser executado no cliente | return JavaScript(“$(’# divTxt’).html(’JavaScript teste’);”); |
| FileResult | Retorna dados binários (arquivo em disco, por exemplo) | return File(@“c:\dados\teste.pdf”, “applicationnpdf”); |
| EmptyResult | Não retorna nada. Igual a void. | return new EmptyResult(); |
| HttpNotFoundResult | Retorna uma página não encontrada | - x - |
| HttpStatusCodeResult | HTTP definido pelo desenvolvedor | Retorna um código de estado |
FileStreamResult |
Envia um objeto Stream para o Navegador | - x - |
HttpUnauthorizedResult |
Envia o código de resposta HTTP 401 para o navegador | - x - |
Com isso quis mostrar a importância das classes controladores em uma aplicação ASP .NET MVC e portanto você deve dar a devida importância a elas.
Rom 8:31
Que diremos, pois, a estas coisas? Se Deus é por nós, quem será contra nós?Referências: