Separação de Responsabilidades e o ASP.Net MVC

  • Article

Separação de Responsabilidades é um princípio de arquitetura antigo (eu acredito que vem do Dijkstra na década de 70) que vêm impactando até hoje um conjunto grande de decisões arquiteturais que vemos em nossas tecnologias. Ela é uma prática recomendável e que deveria ser praticada por todos.

O princípio é simples: fazer com que duas funcionalidades tenham o mínimo de sobreposição.

A Arquitetura Orientada a Serviços (SOA) é um bom exemplo desta separação. Nela, sistemas independentes e autônomos trocam mensagens de forma orquestrada para cumprir uma tarefa. Cada sistema faz sua parte.

Um exemplo: o sistema de RH cadastra novos funcionários, guardando currículos, competências, etc.; o sistema de folha de pagamento inclui o novo funcionário em seus registros; o sistema de diretório cria uma nova identificação para este funcionário (login); e assim por diante. Na SOA, implementamos um caso de uso de Contratação de Funcionário através de um serviço que orquestra cada um destes sistemas. Se for necessário no futuro integrar esta orquestração com o novo sistema (como, por exemplo, o de incluir o novo funcionário no sistema de acesso ao prédio/garagem), basta mudar a orquestração (ou workflow) para incluir esta nova interação com o novo sistema.

Fazer um bom design para SOA significa compreender e aplicar muito bem a Separação de Responsabilidades.

Um segundo exemplo interessante de analisar é o que acontece na Web.

No início, uma página html era carregadas de tags e estes eram carregados de atributos como tamanho, cor, fonte, etc. Em seguida, introduzimos o JScript para navegar na árvore de tags (o DOM) para mudar dinamicamente no browser a aparência do documento. Depois entendemos que as tags têm estilos, como parágrafos de um documento do Word, e criamos o CSS para definir comportamentos visuais do parágrafo retirando a carga das tags. Ao final, temos um html dividido em 3 partes:

  • Definições de Estilos;
  • As tags do HTML que identificam seus componentes (<h1>, <p>, <tr>, etc.) contendo como atributos o mínimo possível (mutas vezes ne a identidade e/ou classe);
  • Definições de comportamentos dinâmicos através de JScripts usando, por exemplo, bibliotecas como o JQuery.

e, com esta Separação de Responsabilidades conseguimos mais clareza e controle sobre a página final gerada.

Por motivos semelhantes o código implementado no servidor sofreu mudanças e logo tornou-se comum o uso do padrão Model-View-Controler. Como todos conhecem o MVC, posso pular esta etapa da história.

Mas, com o tempo, surgiu um passo a mais: a arquitetura REST pede que tenhamos uma correlação clara entre uri’s e uma página web. Isto torna possível que os mecanismos de search apontem e tragam resultados de páginas ativas. O REST também facilita a vida do usuário com uri’s logicas. Esta demanda pelo REST originou a separação entre o roteamento de uma página e a chamada a um Controle do MVC.

Este é o ponto em que estamos hoje. Estas foram as forças que fizeram surgir o ASP.Net MVC !

O ASP.Net antigo não visava tanto o controle de cada parte da geração página HTML final. Sua motivação era produtividade e similaridade com o desenvolvimento de formulários do Windows. Objetivos diferentes sempre levam a decisões arquiteturais diferentes, não é?

Hoje, quando tenho dúvidas de qual utilizar, uso a seguinte regra: sistemas que exigem maior reuso e controle devem ser feitos com ASP.Net MVC. Sistemas que pedem produtividade e não são complexos o suficientes para que o reuso traga impacto devem usar o ASP.Net antigo. Se estiver em dúvida, uso o ASP.Net MVC (simplesmente por ser mais bonito).

O que vocês acham?