Artigo Java Magazine 54 - MVC Model 3

MVC Model 3

Usando DWR como controle de aplicações web

Aprenda como implementar um novo modelo de desenvolvimento web que simula o MVC original com o framework DWR

Nesse artigo, iremos implementar um novo modelo MVC na construção de aplicações web, que chamo de Model 3. Esse modelo tenta se aproximar do MVC original e solucionar os problemas trazidos pelo Model 2.

Frameworks web Model 2 (por exemplo o Struts) implementam o MVC sobre o protocolo HTTP, sem estado, usando padrões que inviabilizaram a manutenção das responsabilidades nas camadas do MVC original ou de suas variações.

No Model 3, usaremos toda a camada lógica de visão e parte da camada lógica do controle na camada física cliente, balanceando o processamento e se beneficiando do poder da linguagem Javascript para  uma melhor usabilidade na interface do usuário.

Usando o framework DWR como controlador da aplicação e aproveitando a maturidade dos frameworks Javascript na camada de visão, usamos o poder de processamento offline das estações clientes e desoneramos o servidor do trabalho da renderização de UI (user interface) como um todo.

Arquitetura da solução

O padrão de arquitetura MVC (Model-View-Controller) se origina na comunidade Smalltalk. Foi criado por Trygve Reenskaug no fim dos anos 70 e se consagrou no desenvolvimento desktop por facilitar o desenvolvimento em camadas de aplicações que seguem a orientação a objetos. Como podemos observar na Figura 1, a camada de visão observa o comportamento do modelo para renderizar a interface do usuário enquanto a camada de controle responde a eventos da visão e solicita modificações na camada de modelo.

Figura 1. MVC original

        A NeXT, empresa fundada por Steve Jobs após sua saída da Apple, resolveu modificar esse modelo oferecendo uma alternativa para sua linguagem de programação Objective-C (uma variação do C com extensões OO inspiradas no Smalltalk). O modelo MVC da NeXT agora delegaria a responsabilidade de observar o modelo para a camada de controle que, por sua vez, empurrava para a camada de visão as alterações ao invés da camada de visão puxar esses dados do modelo, como pode ser visto na Figura 2.

Figura 2. MVC proposto pela NeXT

Com o crescimento do uso da web como plataforma de negócios, as empresas iniciaram um processo de migração de sistemas para o modelo de aplicações baseada no protocolo HTTP, diferente do modelo que as aplicações desktop estavam acostumadas com Swing, onde existe uma sessão aberta entre o cliente e o servidor. Essa migração trouxe novos problemas para o desenvolvimento usando MVC. Como o protocolo HTTP é sem estado por natureza, e também não prevê uma forma de “empurrar” informações do servidor para o cliente, as características originais do padrão MVC ficaram comprometidas.

Para contornar esse problema usando a plataforma Java, a Sun sugeriu um novo modelo que chamou de MVC Model 2, com base no padrão FrontController (quadro Padrão FrontController). Ao tentar recriar o modelo da NeXT em um ambiente sem estado, a camada Controller submete ações tentando acompanhar o processo de request-response do protocolo HTTP ao invés de observar a camada Model, transformando a arquitetura das aplicações em um formato linear (ver Figura 3).

Figura 3. MVC Model 2

Figura 4. Padrão FrontController

Os frameworks da primeira geração Web, como o Struts, surgiram para implementar o modelo sugerido pela Sun.

Alguns fornecedores de implementações de JSF estão tentando implementar algo mais próximo ao modelo da NeXT, usar componentes de visão para identificar por meio de consultas ao modelo, as alterações necessárias na UI (Figura 5).

Figura 5. Model 2 similar ao modelo da NeXT

Com a popularização do conceito de Ajax, notadamente após o lançamento do GMail, o uso do objeto XMLHttpRequest (XHR) conseguiu melhorar o tratamento de requisições do navegador ao servidor, oferecendo maior flexibilidade na construção de aplicações. Hoje, podemos usar uma estratégia de simular o MVC original por meio de estratégias que se beneficiam das conexões assíncronas, permitindo assim usar o Javascript para implementar responsabilidades do MVC perdidas no MVC Model 2. Vários frameworks em linguagens diferentes começaram a popularizar essa nova abordagem, inclusive grandes players do mercado web têm adotado modelos semelhantes em suas principais aplicações, como o já citado GMail, o novo Yahoo!, o Google Docs,  Twitter (microblogging), DowJones (informações financeiras), SlideShare (hospedagem de apresentações) entre tantos outros.

Observe na Figura 6 que no Model 2 todos os processamentos de todas as camadas lógicas são executados no lado servidor. Isso sobrecarrega esta camada e inviabiliza uma melhor usabilidade nas aplicações, já que todas as requisições são síncronas e o usuário espera carregar toda a página para executar uma nova ação. Uma alternativa popular era usar Iframes, que podem ser recarregados individualmente, para simular conexões assíncronas, mas esta estratégia é antiga e caiu em desuso por conta do XHR. 

Figura 6. Disposição das camadas lógicas no Model 2

O proposto Model 3 também é baseado no modelo da NeXT, adaptado a web (como visto na Figura 5). A diferença em relação aos frameworks que processam todas as operações no lado servidor é a distribuição das camadas lógicas de visão e parte da camada de controle para a camada física do cliente.

Parte da camada Controller é construída com a linguagem Javascript, e executada no navegador. Além disso, continua no cliente toda a camada de visão, que se responsabilizará pela renderização usando frameworks Javascript.

O Model 3 sugere a divisão da camada lógica Controller entre fachadas (design pattern Façade).

·         Uma fachada na camada física cliente acessível no Javascript pelo DWR para encapsular o acesso à camada de negócios sem comprometer a segurança no lado servidor (Figura 7).

...