MVC

O padrão MVC: Model-View-Controler foi introduzido originalmente para resolver o problema da interação entre usuário e o sistema de forma que a interação em si fosse isolada das regras de negócio[1]. A View(Visão) representa a interface gráfica propriamente dita, encarregue de desenhar o ambiente interativo é separada das regras de dominio, o Model(Modelo). No meio um mecanismo , o Controler(Controlador) provê a comunicação entre as duas partes.

A visão captura os gestos do usuário como cliques ou teclas precionadas e renderiza o estado do sistema de forma que o usuário entenda. Normalmente de forma multimedia, mas pode ser mais restrita como apenas apresentar texto ou usando uma interface vocal. O modelo representa o resto do sistema. Ele contém regras e/ou dados que têm que ser consultadas. A visão pode consulta do modelo para obter esses dados de forma a poder renderizá-los. O controlador pode utilizar o modelo para executar essas regras. O controlador recebe os eventos “crus” da visão e os interpreta repassando-os ao modelo caso necessário. O controlador pode ainda responder aos eventos do usuário sem consultar o modelo, implementando assim, mecanismos padrão de interação com o usuário.

Ilustração 1: Model-View-Controller (Modelo-Visão-Controlador)

Embora o nome do padrão só contenha três elementos ele é composto na realidade por quatro. O elemento invisivel é o mecanismo de eventos necessário à comunicação entre os outros três elementos. Este mecanismo permite uma comunicação assincrona que apenas é invocada quando algo interessante acontece – o evento. Isso poupa o sistema de ficar consultando dados ou executando regras desnecessáriamente ou num ciclo infinito de repetição.

A implementação do padrão MVC é complexa porque normalmente visa a extensibilidade. A implementação tem normalmente como objetivo criar um controlador eficiente e um mecanismo de comunicação entre as partes. Nesse ponto a Visão e o Modelo são abstraidos como interfaces que o utilizador da implementação pode depois extender e implementar como desejar ( desde que seguindo as regras associadas à interface , claro).

O framework Swing, também chamado de JFC (Java Fundation Classes) – é um exemplo de uma implementação do padrão MVC. O Swing contém os quatro elementos necessários ao padrão:

• Visão – Baseado no AWT e no conceito de Look & Feel o Swing interage com o usuário graficamente e captura seus gestos
• Controlador – Os vários controladores ( ou seja, formas de intrepretar os gestos do usuário) são encapsuladas em diferentes componentes que podem ser compostos (padrão Composite) para produzir interações ricas. Clicar num botão ou numa imagem é o mesmo evento para a visão, mas diferentes eventos conforme onde o clique acontecer, conforme o componente que está naquele local da tela.
• Modelo – O Swing abstrai todos os modelos através de interfaces especificas para cada controlador que os utiliza.
• Modelo de Eventos – O Swing é implementa um modelo de tratamento de eventos que une as outras três partes. No caso especifico do Swing esse modelo é associado a um modelo especifico de threads [2]

O Swing oferece três formas de extensão: uma para cada componente do padrão. É possivel construir vários modelos que alteram o funcionamento dos componentes. É possivel associar diferentes componentes (Controladores) de forma criar novos controladores. Finalmente, é possivel criar novas experiências de interação – várias visualizações – alterando o Look & Feel da visão.

MVC e Web

Infelizmente ou não, o introdução do java no mercado sempre foi pela area se sistemas web e não pelos desktop. Estes sistemas têm a necessidade de interagir com o usuário e como tal o padrão MVC foi adaptado para o novo paradigma.

Numa primeira aproximação os sistemas web são um conjunto de páginas dentro de um mesmo contexto. A tecnologia primordial para o a construção de sistemas web em java foi o uso de Sevlets. O Servlets são classes que recebem uma requisição e retornam uma resposta. Em particular, recebem requisições HTTP e retoram HTML. Esta tecnologia era poderosa. Permitia fazer qualquer coisa possivel em Java, mas dificultava a construção de HTML já que Servlets são programados com Java incluir os tags HTML torna-se chato. Além disso, programar um Sevlet torna-se manipulação de String.
Alternativas a esta utilização se seguiram num conjunto de melhores práticas. Servlets eram agrupados. Uns construiam apelas o HTML enquanto outros continham as regras de processamentos dos dados. E isso era o mais perto de um MVC que podiamos chegar. Este mecanismo é designado MVC: Modelo 1.

Por motivos de simplicidade ( e quero crer de concorrência ) foi introduzia a tecnologia Java Servlet Pages ( JSP). Esta tecnologia era baseada na de Servlets não deixava a página ser escrita em HTML com ilhas de java. A escrita era simplificada e era agora mais fácil modificar a aparência ou organização da página. A JSP trouxe uma tecnologia que permitia agora implementar a Visão de uma forma mais simples. As interações iniciavam-se na página, eram dirigidas ao servlet que contém a logica de processamento que digire o fluxo para a mesma , ou outra, página. Este processo ciclico que utiliza a página JSP como implementação da visão e um conjunto de servlets como controladores e modelos é uma evolução em relação ao modelo anterior e designa-se do MVC: Modelo 2. Este é o padrão que a maioria dos frameworks web segue.

Com o advento do JSP é possivel utilizar páginas para realizar o serviço dos servlets controladores ( na realidade as páginas JSP são convertidas em Servlets por detrás dos panos). Este modelo ainda é o MVC : Modelo 1, apenas utilizando uma tecnologias difernete. O ponto é que a mesma tecnologia é utilizada para todos os elementos do padrão, o que, como vimos, não é produtivo.

É comum que uma página HTML seja embutida de capacidades de processamento usando tecnologias do lado do cliente como Javascript. Esse javascript é escrito pelo elemento Visão mas ele exerce capacidades de Controlador no cliente. Esta mistura de tecnologias derivada das limitações do HTTP e do HTML levam as pessoas a pensar que a Visão é aquilo que acontece no navegador. Aquilo que acontece no navegador, a interação dele com o usuário também segue o padrão MVC, mas a implementação do padrão é, neste caso, da responsabilidade do navegador ele mesmo. A visão do sistema que fica no servidor atua como modificador da implementação MVC no navegador. Usando Javascript é possivel exercer o papel de controle, modificar a experiencia visual e até os dados que usuário vê. Este é um exemplo simples e claro como o padrão MVC se aplica a apenas uma camada e andar de cada vez, mas pode ser aplicado consecutivamente em várias camadas e andares. Neste caso a visão da camada mais abaixo terá que comunicar com o Modelo da camada mais acima. Ou, como no exemplo , comunicar como a implementação como um todo. O inverso, contudo, não é verdadeiro. A camada superior não se pode comunicar com nada além da visão da camada inferior. Essa é afinal, a essência do padrão Façade de que a visão é uma especialização.

Não alheios ao fato do navegador desempenhar uma função critica na interação da aplicação com o usuário, a implementação MVC presente no próprio navegador tem que ser entendida como uma camada essencial ao sistema em si mesma.

Isto levou a criar uma camada em javascript que funciona no navegador e se comunica com o servidor utilizando o protocolo HTTP de forma assincrona. Isso gerou o padrão Ajax ( Assincronous Java And XML). O XML da sigla deve-se a utilizar esse padrão como forma de formatar os dados como num protocolo de comunicação. Hoje em dia alternativas existem como o JSON.

A camada Ajax funciona então como um modificador da implementação MCV padrão do navegador. Essa camada comunica com o servidor. Como o servidor não mais se preocupa com a interação com o usuário poderiamos pensar que ele não mais implementa o padrão MVC. Contudo ele ainda tem que comunicar com a camada Ajax que roda no navegador. Essa comunicação é a Visão da camada que roda no servidor.

Analisando o padrão

Podemos abstrair o uso do padrão dizendo que a Visão interage com uma entidade – o cliente- que pode ser humana, um outro sistema ou sub-sistema. Por outro lado, o modelo pode comunicar com outras camadas ou sistemas.

É importante entender que o padrão MVC é uma forma de implementar uma camada do sistema e não é uma forma de ligar camadas do sistema. Alguns dos conceitos do MVC podem ser utilizados para fazer camadas comunicar entre si ( baixo acoplamento, por exemplo) mas não constituem em si mesmas o padrão MVC sem que sejam associadas a uma só camada. O MVC é uma forma de organizar as classes de uma camada seguindo o Principio de Separação de Responsabilidade.
As camadas, por definição, já são aplicações do mesmo principio , logo , não faria sentido uma separação extra.

Devido a esta confusão existe um dilema na hora de classificar o padrão MVC como sendo um padrão de arquitetura ou de projeto (design). Ele seria um padrão de arquitetura se suas responsabilidades se ligassem a requisitos não funcionais, se abarcassem mais do que uma camada, nodo ou andar. Caso contrário seria apenas um padrão de projeto.

Sendo que o padrão se restringe a uma só camada ele não pode, obviamente ser considerado um padrão de arquitetura. Contudo, a escolha deste padrão para uma certa camada ( normalmente a de cliente) pode estabelecer ou necessitar de um apoio dado pelos requisitos não-funcionais. Mas essas “extensões” serão sempre feitas à custa de implementações especiais da Visão, do Controlador ou do Modelo que em si delegam para outras camadas, andares , nodos ou sistemas. Por exemplo, numa aplicação desktop construida com Swing o modelo terá que interagir com um servidor, ou com o banco de dados presente em outra máquina. Embora o sistema tenha uma arquitura distribuida a implementação do padrão existe apenas num única camada e nodo do sistema. Como vimos antes, em uma aplicação web, a visão da aplicação que corre no servidor tem que interferir com os mecanismos do navegador para produzir a visualização final. Embora a visão do servidor manipule os três elementos da implementação MVC do navegador, ela não acumula os papeis de controlador ou modelo da sua própria camada.

Enfim, embora o padrão MVC não seja um padrão de arquitetura a sua implementação é fortemente influenciada por ela. Do mesmo modo a arquitetura é influenciada pelas implementação MVC que podemos utilizar nas diferentes camadas. O padrão MVC seria melhor descrito como um padrão de implementação: uma simbiose entre arquitetura e design.

Relação com outros padrões

O padrão MVC é na realidade um uso particular de alguns outros padrões que se tornou ele mesmo um padrão. O Modelo é uma especialização do padrãoFaçade já que esconde todo o modelo de dominio/negocios e dados. A Visão também é uma especialização ddo padrão Façade escondendo do usuário todos os detalhes da aplicação. O Controlador pode ser entendido como uma especialização do padrão Mediator com a diferença subtil que embora ele medie a comunicação, ele não media toda a comunicação.
A comunicação com uso de eventos é a aplicação do padrão Observer.

Licença

Sérgio Taborda Este trabalho é licenciado sob a Licença Creative Commons Atribuição-Uso Não-Comercial-Não a obras derivadas 3.0 Genérica .