ASP.NET MVC – Design de controllers – Parte 1


Numa aplicação Asp.net MVC ,controllers existem para responder qualquer requisição que um usuario faça através da interface de usuario.Qualquer interação entre a aplicação e o usuario é geralmente descrita como use-case.Como arquiteto,você começa a partir do user-case pra ter uma idéia clara das funções que devem estar disponiveis para o usuario na aplicação.

Sua próxima tarefa é simplesmente mapear funções para a classe controller.

Não existem razões técnicas que o impeçam de ter uma única classe controller que englobe toda a aplicação;e da mesma forma não existem razão técnicas que o impeçam,de ter uma classe controller para cada possível requisição.

Você está agora no momento de particionar o conjunto de funções num número balanceado de classes controller.Como você faz isso,depende das funções e mais o mais importante,da visão da aplicação que se origina do user-case.Como via de regra,você deve se preocupar em ter uma classe controller para cada entidade significante na solução da sua aplicação.

Num site comercial,é comum você encontrar use-cases que precisem de operações CRUD (Create,Read,Update,Delete) em clientes,pedidos,detalhes do pedido, e faturas.Você pode então iniciar com um OrderController para permitir que usuarios criem um novo pedido,assim como atualizar ou deletar pedidos.Fazendo isso,você deve estar focado nas necessidades da camada de apresentação,e colocar de lado,como irrelavente no momento,as necessidades da entidade modelo da camada de negócios.

Se você lida com pedidos,você provavelmente também lida com detalhes do pedido e produtos.Porém,apesar de Pedidos,Detalhes do pedido,e produtos serem bons candidatos a se tornarem membros do modelo de entidades (ou domain model,se você aplicar a metodologia domain-driven),somente Pedidos faz sentido como inspirador da criação de uma classe controller.A partir da perspectiva da interface de usuario,na verdade,um usuario irá enviar comandos somente para criar,atualizar ou deletar pedidos.Nesse caso,é OK ter um OrderController,mas não é OK ter um OrderDetailsController.Uma regra simples é a seguinte.

Ter um contoller para cada entidade de negócio que é diretamente exposta na camada de apresentação.

Esse poder ser apenas o primeiro passo,no entanto.

Suponha que um dos use-cases determine que você deva fazer com que os usuarios possam visualizar faturas.Um InvoiceController seria então util para servir as necessidade do usuario.Num site comercial,no entanto,provavelmente você vai disponibilizar uma seção de back-office para controle administrativo,como processamento de pedidos e faturas.Nesse caso,pode ser util tem uma classe controller distinta para suportar operações de back-office para pedidos e faturas.Outra regra simples é a seguinte:

Tenha uma classe controller para cada entidade da camada de negócio que é exposta diretamente na camada de apresentação e pra cada contexto operacional.

No fim das contas,o mapeamento de funções para controllers,e o subsequente mapeamento de métodos para controllers,certamente não é uma ciência exata.Porém,com a correta e sistemática aplicação dos principios da chave de design,você pode obter um design que seja aceitavel para todas as partes interessadas no projeto.O principio é o Single Responsibility Principle – SRP (Principio da Responsabilidade única).As duas regras simples citadas anteriormente fazem parte do SRP.

Mapeando comportamento de métodos

No todo, a parte mais complicada do processo de design é mapear as funções para os controllers.Depois de você ter estabelicido uma lista aceitavel de controllers,deve ficar claro quais métodos pertecem a quais controllers.Métodos de um controller são conhecidos como Actions – e o nome não poderia ser mais apropriado.Num controller,você tem um método para cada ação do usuario, o que acaba caindo na (única) responsabilidade do controller.

Como você codifica um método de um controller?O template de um método pode ser resumido no seguinte:

  • Recuperar dados de entrada – Um método pode obter argumentos de entrada de várias fontes:route values e coleções expostas pelo objeto Request.O ASP.NET MVC não impõe uma assinatura particular para métodos de um controller.Para testes,é preferivel que qualquer parametro de entrada seja recebido através da assinatura do método.Evite,se você puder métodos que recuperem parametros programaticamente através do objeto Request.Pré-condições também ajudam a garantir que não hajam valores incorretos passados nas camadas do sistema.
  • Realizar a tarefa – Nesse momento,o método realiza o seu trabalho baseado nos argumenos de entrada e nos resultados esperados.Na maioria das vezes,o método precisa interagir com a camada intermediária e qualquer dessas interações é feita através de serviços dedicados.Validações de valores calculados ocorrem também nesse estágio.
  • Preencher o View-Model – No fim da tarefa,qualquer valor que deva ser incorporado na resposta é adicinado ao view-model.O view-model pode ser um dicionario plano de key/value,ou um objeto strong-typed especifico daquela view.
  • Preparar o objeto result – Um controller não é responsável por produzir a resposta em si.Ele é responsavel,por disparar o processo que irá usar um objeto View distinto para renderizar o resultado para a saída.O método identifica o tipo da resposta (file,plain data,HTML,JavaScript,ou JSON) e prepara um objeto ActionResult de acordo.

Parece fácil de maneira geral?Bom,outro aspecto complicado é como você elabora o código que executa a tarefa.Mas isso fica para a próxima parte de design de controllers.

Até lá!

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s