MVC baseado em ações no Java EE

Muitos dos programadores da atualidade não vivenciaram o início do desenvolvimento para a web, há quase 20 anos, quando linguagens como ASP (Active Server Pages) e PHP (Hypertext Preprocessor) dominavam a preferência dos desenvolvedores da época. Nesse tempo, quando os desenvolvedores ainda estavam engatinhando nesse novo paradigma de desenvolvimento e poucos padrões eram utilizados, era muito comum encontrar o que convencionamos chamar atualmente de código-espaguete: um código no qual misturávamos em um único arquivo a lógica de apresentação e negócio, além de diversas linguagens, como HTML, JavaScript, ASP/PHP/JSP e CSS.

Quem já teve o desprazer de dar manutenção em um código-espaguete sabe o quanto essa tarefa é e cansativa e desestimulante, uma vez que esse tipo de código é extremamente complexo e dificulta a aplicação de conceitos básicos de reaproveitamento de código. Como resposta a esse problema, alguns frameworks foram criados visando um código mais limpo, reaproveitável e de fácil manutenção. Basicamente, eles usavam padrões que orientavam o desenvolvedor a criar sua aplicação em camadas lógicas que separavam o código de negócio e persistência de dados do código de apresentação, também conhecido como Visão.

Entre os muitos padrões utilizados por esses frameworks, o MVC, sigla para Modelo-Visão-Controle, logo se tornou bastante badalado e, desde então, virou o preferido da grande maioria dos frameworks para a web. Entretanto, uma rápida pesquisa na Internet nos revela uma boa quantidade de variações, ou reinterpretações, desse padrão, sendo que atualmente as duas mais usadas no mundo Java são o MVC baseado em componentes e o MVC baseado em ações.

Assim que o Java entrou no mundo do desenvolvimento web, também era comum encontrarmos diversos códigos-espaguete, predominantemente feitos com a tecnologia JSP (JavaServer Pages). No entanto, a comunidade Java respondeu muito rapidamente a esse problema, criando frameworks como o Struts, Tapestry, JSF e muitos outros. Desde então, esse padrão é amplamente utilizado para a criação de aplicações web em Java, tanto que agora ganhará uma JSR específica para ele, chamada de MVC 1.0.

Neste artigo, analisaremos essa nova JSR através de um exemplo prático usando a implementação de referência, chamada Ozark. Trata-se de uma aplicação simples de cadastro de produtos, cujo objetivo é detalhar essa JSR e como ela poderá ser utilizada em seus futuros projetos.

O Padrão MVC e suas variações

O padrão MVC surgiu na década de 1970 e foi criado por Trygve Reenskaug para a linguagem Smalltalk. Inicialmente, ele foi criado para ser usado no desenvolvimento de aplicações para desktop, mas, posteriormente, com o advento da web, passou a ser adotado em frameworks escritos em praticamente todas as linguagens disponíveis para essa plataforma. Dada sua importância no desenvolvimento de softwares, Martin Fowler escreveu: “o MVC foi a primeira tentativa de padronizar a construção de aplicações com interfaces gráficas”.

O objetivo desse padrão, desde a sua concepção, é separar a aplicação em camadas lógicas, deixando clara a responsabilidade de cada camada para evitar, por exemplo, que um código que é responsável pelo acesso ao banco de dados esteja misturado com um código cuja responsabilidade é exibir uma caixa de texto na tela.

Basicamente, temos três camadas nesse padrão, chamadas de Modelo, Visão e Controlador. A camada de modelo é responsável pela lógica do negócio e persistência dos dados da aplicação. No MVC, o modelo deve ser totalmente independente da visão, podendo ser reutilizado com qualquer outra tecnologia de apresentação. A visão, por sua vez, é responsável apenas por apresentar a tela da aplicação, como caixas de texto, listas de seleção, etc. Por último, temos o controlador, responsável por responder a eventos originados da interação do usuário com os componentes da tela e funciona como um intermediário entre o Modelo e a Visão, já que esses dois nunca podem interagir diretamente.

Contudo, o padrão MVC não se manteve estático durante todos esses anos. Diversas variações foram criadas, cada uma tentando resolver novos problemas que surgiam em decorrência da própria evolução das tecnologias. Entretanto, embora variem em alguns aspectos, todos eles se enquadram no padrão que Martin Fowler nomeou como Separated Presentation. Esse padrão é a base de todos eles e tem como principal foco a ideia de que a lógica de negócio deve sempre ser representada por uma camada totalmente independente da camada de apresentação, conforme já discutimos anteriormente.

Entre os muitos padrões que estendem o MVC, temos: MVP (Model-View-Presenter), MVA (Model-View-Adapter), AM-MVP (Application Model – Model-View-Controller), etc. Mais recentemente, duas novas opções de MVC, totalmente direcionados ao ambiente web, foram sugeridos pela comunidade: o MVC baseado em Ações e o MVC baseado em Componentes.

MVC baseado em componentes

Nesse padrão, temos uma interface gráfica totalmente construída através da composição de componentes e por um arcabouço que é responsável por esconder do desenvolvedor toda a lógica envolvida no tratamento do fluxo de requisições e respostas do protocolo HTTP. Por exemplo, o programador não precisa se preocupar em guardar o estado da aplicação entre múltiplas requisições ou, em tese, sequer precisa conhecer JavaScript para ter à sua disposição as chamadas AJAX, tão comuns no desenvolvimento web da atualidade.

Entre algumas das responsabilidades de um framework baseado nesse padrão, estão:

· Tornar transparente ao usuário a construção de URLs;

· Guardar o estado da aplicação entre múltiplas chamadas;

· Isolar o desenvolvedor das complexidades envolvidas no tratamento de requisições HTTP;"