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

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?

Comments

• Anonymous
  August 27, 2010
  Ótávio post bacana, e realmente amadurecer, é valorizar conceitos como este. Separar responsabilidades, é fundamental para quem quer sistemas bem estruturados e de fácil manutenção. Pois havendo responsabilidades claras, não só passamos a ter um código mais limpo, como também, de manutenção mais fácil. Abraços

• Anonymous
  August 27, 2010
  Boas Otavio, Eu já utilizei bastante o ASP.NET WebForms pelos projetos que trabalhei, e que eventualmente, eu dou manutenção. Quando o ASP.NET foi concebido, apesar de ainda não estar nesta área, a ideia da Microsoft foi tentar diminuir o abismo que existia entre o desenvolvedor Windows e o desenvolvedor Web, e a tua frase encaixou perfeitamente neste contexto: "Objetivos diferentes sempre levam a decisões arquiteturais diferentes.". Devida a essa "necessidade" que a Microsoft tinha, o ASP.NET ficou extremamente "overkill", ou seja, a complexidade da requisição, do ciclo de vida da página, entre outras coisas, que para aqueles que desenvolvem aplicações web "puras", o ASP.NET se tornou tudo muito mágico, e ao mesmo tempo, complicado. Se você não conhecer detalhes internos (tais como processamente assíncrono, control adapters, gerenciamento de estado e alguns detalhes do runtime), dificilmente você conseguirá tirar todo o poder que ele te oferece. A questão de testes sempre foi um prolbema com o ASP.NET Web Forms, devida a sua afinidade com o IIS, mas há algumas alternativas que ajudam nisso, como é o caso do padrão MVP, que nos auxilia a tornar o WebForms testável, e ainda, se não me engano, há ferramentas de testes que conseguem fazer ele funcionar mesmo sem rodar no IIS. Mas se você tem tudo o que compõe as regras de negócios, workflows e serviços (o "coração") devidamente protegidos e cobertos por bons testes, você pode consumir em uma aplicação qualquer, seja ela qual tecnologia for, afinal, será somente a "casca". Eu gosto da separação que o MVC faz com relação aos controllers. O que não gosto muito é da sintaxe para escrever algo na View <% %>, ou mais recentemente, <%: %>. Olho para o código e acho difícil interpretá-lo. Agora o Razor deixa isso muito mais suave e simples. Atualmente eu tenho desenvolvido mais em cima de ASP.NET MVC do que em WebForms, e percebo com isso, que uma das principais melhorias é que a escrita do código fica bem menos dependente da infraestrutura do que no WebForms. No MVC você está mais livre, mais a vontade para escrever um código "limpo". No ASP.NET WebForms, se você não tomar cuidado, tudo o que a sua aplicação terá, será uma porção de event-handlers para tratar os controles e a página, orientando à uma programação extremamente procedural. Mas como eu disse antes, tudo isso se deve a forma como cada tecnologia foi desenvolvida. Mas isso não faz o WebForms um grande vilão. Acho que devido a complexidade dele, a "caixa preta" em que o mesmo vive, faz com que muitos dos detalhes internos não sejam observados, tornando ele, às vezes, pior que o ASP Clássico. Uma certa vez eu li em um blog internacional: ASP.NET MVC é para Web Sites enquanto ASP.NET Web Forms é para Web Applications. Eu acho que não seja tão linear assim, mas eu também não diria que com o WebForms você não consegue construir boas aplicações/sites. De qualquer forma, eu vejo que o ASP.NET MVC tem cada vez mais espaço no mercado. Na empresa em que trabalho estamos adotando ele para alguns protótipos de aplicações, e ele se saiu bem. Como MCT, eu já ministro treinamentos desde 2006, e pude perceber nos cursos mais recentes de ASP.NET, em cima do Visual Studio 2010, que a Microsoft dividiu em 80% para MVC e o resto para WebForms. Talvez isso represente alguma coisa.

• Anonymous
  August 27, 2010
  É isso aí, Otávio, right on. A maioria dos sistemas que encontro hoje se beneficiam mais com ASP.NET MVC. Webforms tem ainda seu espaço, mas vejo ele bem reduzido. Mas o ASP.NET MVC ainda tem um problema: falta de mâo de obra. Mas esse é um problema que se resolve sozinho, e, de fato, já está se resolvendo. Postei sobre essa escolha no meu blog 2 anos atrás: unplugged.giggio.net/.../ASPNet-MVC-Quando-Usar.aspx Quanto à separação entre HTML, js e CSS, concordo plenamente. No podcast que gravei com o Victor Cavalcante no Tecnoretórica ele exemplificou belamente como essa interação se dá. Mais: www.tecnoretorica.com.br/.../victor-cavalcante []!

• Anonymous
  August 27, 2010
  Otávio, parabéns pelo post. Eu trabalho com SOA e asp.net MVC e concordo plenamente com você, quando comecei a trabalhar com asp.net, eu utilizava a versão 1.1 do framework, era sofrível fazer uma simples aplicação tendo como herança o aprendizado do asp clássico da década de 90. Aplicações web são stateless, um grande esforço foi feito para simular um contexto de web application statefull com webforms, os problemas se tornaram públicos e notórios, fora a questão da separação de responsabilidades. Ninguém merece trabalhar com ViewState da forma que foi obrigado no passado, seja conscientemente ou inconscientemente com utilização de ScriptManager e outras estruturas do asp.net webforms. Quanto a separação de responsabilidades: Se não há distinção entre conteúdo e estruturas de controle, como assegurar que uma camada de apresentação possa ser manutenível? Se alterações de layout e conteúdo se misturam, a apresentação dos dados fica fortemente acoplada com a própria organização dos dados, prejudicando o desenvolvimento. Fico extremamente contente em ler posts como estes escritos em português e por profissionais brasileiros, trabalho com asp.net mvc desde a versão 1.0 e a maioria dos artigos que defendem esta arquitetura eram escritos por profissionais fora do Brasil.

• Anonymous
  August 28, 2010
  Otávio, excelente o post! Seus argumentos são completamente pertinentes e estão muito bem expostos. Mas um detalhe engraçado que noto é ver a comunidade Java, até pouco tempo atrás, usando argumentos contrários para justificar o desenvolvimento com Java Server Faces ao invés do velho Struts e seus ActionControllers. Claro que são épocas diferentes entre o Struts e ASP.NET MVC, mas aprimorar conceitos para reutilizar sempre agrega e sempre será bem-vindo! E é assim que eu vejo o ASP.NET MVC... Portanto eu acredito que ambas as abordagens tenham espaço na concepção de sistemas. Nessas horas sempre vale a máxima: Você nunca corre o risco de entregar um software bom se contar com programadores ruins.