Este post é o quarto e último de uma série de traduções de artigos do blog Design Codes, que falam um pouco sobre a evolução do padrão MVC desde o final dos anos 70, até chegar aos dias de hoje, momento em que uma de suas variações - o MVP - está se popularizando, tendo inclusive sido citado como uma best practice no Google I/O 2009 para o desenvolvimento de aplicações GWT.
Clique Aqui Clique Aqui Clique Aqui
O padrão Model-View-Presenter foi publicado em 1996 por Mike Potel, para se tornar o modelo de programação da próxima geração de aplicações Java e C++ da época. A arquitetura MVP era baseada no modelo de programação MVC clássico do Smalltalk, que era o mais comum naquele tempo, e que inspirou muitas outras bibliotecas e frameworks. Potel descreveu o MVP como um modelo unificado que era adaptável a aplicações multi-camadas e a múltiplas arquiteturas cliente-servidor.
Este artigo revisa o padrão MVP proposto por Potel, focando em sua implementação em aplicações Cliente-Servidor. Use os links acima para conhecer mais sobre a evolução do MVC. Ao final do artigo, existem links para blogs que dão exemplos de implementações do padrão MVP.
MVP em aplicações Desktop
O MVP de Potel inclui seis abstrações: View, Interactor, Presenter, Command, Selection, and Model.
É possível criar uma aplicação usando todas as seis abstrações:
- Model: serve para interagir com o banco de dados, e armazenar informações.
- Selection: usado para definir um subconjunto de dados selecionados.
- Command: executar operações em uma Selection.
- View: Desenhar a aplicação na tela.
- Interactor: lidar com os eventos do usuário e invocar o Command apropriado.
- Presenter: criar o Model, a View, as Selections, os Commands e Interactors, e gerenciar as interações entre eles para prover as funcionalidades da aplicação.
O modelo mais simples possível é ter apenas entidades Presenter, acumulando as responsabilidades do Model, da View e do Interactor. A View pode ser adicionada em seguida, para blindar o Presenter das responsabilidades de desenhar a aplicação na tela; Um próximo passo seria adicionar Interactors para tratar os eventos do usuário; e assim por diante, os elementos podem ser incrementalmente adicionados, sob demanda, à arquitetura.
Os desenvolvedores do Smalltalk adotaram uma variação MVP/Dolphin, que contém apenas os elementos Model, View e Presenter, com o Presenter acumulando as responsabilidades do Interactor, Command e Selection, ficando encarregado de responder aos eventos dos usuários, manter uma seleção de dados, e executar operações sobre esta seleção. Mais detalhes em Do MVC para o MVP.
Colaboração
Vejamos como o MVP pode ser usado como modelo base para uma GUI simples de uma aplicação chamada "Impressão de Registros". Há apenas um caso de uso: o usuário clica no botão imprimir, e o registro selecionado é impresso.
A modelagem MVP para esta GUI terá apenas uma View para desenhar a lista de registros, e um botão Imprimir; dois Interactors - um para capturar o clique do botão, e um para capturar a seleção de um registro na lista; um Command, para enviar o registro selecionado para a impressora (Model); um Selection, para armazenar o registro selecionado, e um Presenter, para criar a View, o Command, os Interactors, e realizar as interações entre cada entidade.
- O usuário seleciona "Record-1"
- o Interactor da lista captura o clique e faz a Selection apontar para Record-1
- A view é atualizada para destacar o registro selecionado
- O usuário clica no Botão Imprimir
- O Interactor do Botão intercepta o clique e executa o PrintCommand
- O Command verifica a Selection atual e envia para a impressora
MVP em aplicações cliente/servidor
No artigo descrevendo MVP, Potel sentencia que uma vasta gama de arquiteturas cliente-servidor podem ser modeladas através de variações simples do modelo MVP: em aplicações "fat-client", onde consultas SQL geradas no próprio cliente são mandadas através da rede; e em aplicações "thin-client", onde comandos são mandados para o servidor, e este atua sobre os comandos, para gerar o SQL apropriado.
Fatorando o Modelo
Uma forma de implementar a arquitetura MVP em aplicações Cliente-Servidor é dividir o modelo entre ao lado cliente e o lado servidor. Ou seja, haverão classes, em ambos os lados, representando um mesmo modelo conceitual. As entidades MVP residiriam todas no lado cliente, e o Modelo em si no servidor. Os modelos no lado cliente agem como proxies para os modelos reais que residem no lado servidor, nos quais ocorre a interação com os bancos de dados, e outras interações da lógica de negócio.
Nas aplicações atuais, o Interactor não mais é necessário, desde que os próprios Widgets sejam capazes de lidar com os eventos dos usuários (leia mais a respeito no tópico "problema da aplicabilidade" neste artigo). Já o Command e o Selection podem ser encapsulados no Presenter. Esta abordagem MVP simplificada é comum em arquiteturas de aplicações rich-client.
Em muitas aplicações de TI, o modelo reside inteiramente no lado cliente, enquanto o servidor é meramente um Sistema Gerenciador de Banco de Dados (SGBD), ou um web-service que encapsula o banco de dados.
Fatorando o Presenter
Outra forma de implementar uma arquitetura MVP em aplicações cliente-servidor é dividir o Presenter entre o cliente e o servidor: em arquiteturas fat-client, a lógica de negócios reside na parte do presenter que reside no lado cliente, com um presenter mais simples rodando no servidor; Em arquiteturas thin-client, a parte simples do presenter fica no lado cliente, enquanto o presenter no lado servidor lida com a lógica de negócios.
Em aplicações cliente-servidor onde o presenter onde o Interactor reside no lado cliente e o Command no lado servidor, o Interactor não tem como se comunicar diretamente com o Command. Neste caso, o interactor captura os eventos do usuário, e delega à contraparte cliente do presenter para lidar com eles. O presenter no lado cliente interpreta o evento e envia uma mensagem apropriada para sua contraparte no servidor, e esta sim executa o Command.
Nenhum comentário:
Postar um comentário