Mediadores, Views e Camadas 

May/12
14

No ultimo post o meu objetivo era discutir a melhor tecnologia de view e concluir que n√£o ha a melhor e que o ideal – o esperado em uma implementa√ß√£o robusta – seria views tira-p√Ķe de modo a n√£o amarrar o resto das camadas com a view.

Hoje existem algumas poucas tentativas para isto. A mais conhecida √© o uso de REST. A ideia √© ter um web server/container que prov√™ respostas as URL. Ent√£o, um aplicativo independente pode ser criado para utilizar essas intera√ß√Ķes HTTP para produzir funcionalidade agregada e “bonita” naquilo que se est√° chamando de rich cliente (“cliente rico”). Ok. S√≥ tem um detalhe. Se a aplica√ß√£o quiser otimizar ou prover uma funcionalidade nova n√£o √© poss√≠vel sem modifica√ß√£o da contraparte REST. Podemos argumentar que a otimiza√ß√£o √© um problema que pode ser deixado para ultimo e/ou n√£o levado em considera√ß√£o numa primeira analise. Afinal os browsers s√£o otimizados paras as mesmas respostas HTTP sem saber bem o que vem do outro lado. Coisas como zipar o conte√ļdo ou controlar o cache de respostas dadas pelo servidor podem ser controlados pelo servidor e desabilitadas pelo browser. Funciona. Mas sempre tem aquele cookie que vc precisa aceitar. Ou seja, estado. O browser precisa armazenar estado para otimizar a comunica√ß√£o.

Mas REST vai contra isto de estado. Ok. Neste cen√°rio poder√≠amos implementar um UI em javascript e uma em Swing e tudo estaria correto do ponto de vista da independ√™ncia parcial. O servidor √© livre de prover mais funcionalidades a qualquer momento e o cliente de as usar. O cliente √© livre de deixar o usu√°rio brincar com o dados e janelas como quiser. Claro que o cliente n√£o pode criar funcionalidade do zero, mas pode- por exemplo – fazer o mashup de v√°rios servidores para chegar em um cliente interessante. Por exemplo, integrar o google maps com o REST de cadastro de lojas. O detalhe √© que nestes mashups o cliente vira a aplica√ß√£o, o servidor de dados REST √© apenas um Banco de Dados virtualizado num URL. Esta √© exatamente a arquitetura que o Android usa, com a diferen√ßa que os dados podem ficar no pr√≥prio aparelho. Mas vc √© livre de usar os dados de um aplicativo em outro (dadas as permiss√Ķes, etc…) Ou seja, as camadas do “DAO para baixo” s√£o expostas como REST e as camadas para cima como uma aplica√ß√£o diferente. O Business fica em algum lugar no meio. Podemos ter REST que salvam, validam, d√£o update, etc.. mas podemos deixar todas as regras de valida√ß√£o na aplica√ß√£o e usar o REST como um dao burro. “Podemos” – n√£o quer dizer que √© a melhor forma ou a mais usada. Depende muito se os dados s√£o read-only ou write-almost-never ou se √© um servi√ßo transacional pesado como s√£o telas de cadastro.

Bom, isto √© uma solu√ß√£o poss√≠vel nos nosso dias. Passa por alguns pontos interessantes, mas n√£o √© bem o que eu estava pensando quando falei do padr√£o Bridge (Mediator). O padr√£o Mediator seria mais no n√≠vel do c√≥digo/ bibliotecas/ camadas, √† semelhan√ßa do JDBC por exemplo.¬† Pense assim, o JDBC est√° para o banco de dados como este mediador de UI est√° para¬† a ui. O “driver” seria a implementa√ß√£o da API do mediador para a tecnologia de view em causa. O “driver” deveria permitir tr√™s coisas b√°sicas : dirigir o fluxo ,¬† coletar/apresentar dados, responder a eventos. Note-se que estes eventos, dados e diretor de fluxo s√£o levantados pela UI verdadeira ( struts, jsf, etc… ) mas tudo √© canalizado para este “driver” invertido” de forma que o mediator possa entender os dados e comunicar com o outro lado dos business.

Se voc√™ entendeu o que falei , vc deve estar pensando “mas isso √© o que a action do struts faz”. Sim. √Č o que ela faz. Assim como o managed bean do jsf e outros objetos que cumpre este papel em outro frameworks. Estes objetos s√£o um pouco business delegate ( porque cont√™m algumas regras de negocio) e um pouco view controler porque dirigem o fluxo.

As pe√ßas s√£o mais ou menos obvias e se virmos com aten√ß√£o est√£o presentes em todos estes frameworks “compativeis”. Para come√ßar temos o Dispatcher. Este √© o cara que trata a navega√ß√£o. Come√ßa com o pr√≥prio dispatecher da Servlet API pura at√© ao pr√≥prio struts em si mesmo. E todos os frameworks web usam isto, afinal tem que ser poss√≠vel pular de um URL para outro dentro do servidor (forward) ou instruir o browser a pular para outro URL (redirect). Basta termos um objeto POJO -like que n√£o use construtos muitocomplexos (apenas, por exemplo, simples strings ou enums de algum tipo ) para pular para outro “cena”. Este conceito de “cena” em vez de janela ou p√°gina ajuda a pensar que o usu√°rio ir√° ver outra coisa, sem sabermos onde a ir√° ver.¬† Para pegar dados o velho padr√£o View Object √© simples de usar e com os recursos de atuais √©¬† o que j√° usamos. Se bem que adoramos usar as entidades de banco de dados para este fim, mas nada mais se trata do que capturar todos os par√Ęmetros em um POJO e deixar o framework implementar os detalhes da copia, convers√£o, etc.. Para responder a eventos temos aquilo que definimos como “actions” que podemos entender como m√©todos em que o nome do m√©todo corresponde com a a√ß√£o. Obviamente este mapeamento acontece na real implementa√ß√£o da view, mas os m√©todos do mediador s√£o sempre os mesmos.

Quase todos os objetos que identificamos como “actions” se comportam assim e t√™m estes acessos a API semelhantes. Se enxergarmos do ponto de vista do mediador para fora em dire√ß√£o ao browser iremos enxergar que um conjunto de padr√Ķes de uso se repetem, da mesma forma que enxergamos do business em dire√ß√£o do DB que muitos padr√Ķes de uso se repetem. Quando estamos na camada de business e olhamos o banco de dados que fica na camada de recursos e nada mais √© que o um arquivo glorificado, pensamos na camada de integra√ß√£o onde ficam coisas como o JDBC, JPA e companhia. Quando olhamos da¬† camada de business em dire√ß√£o ao usu√°rio que est√° usando a camada cliente pensamos na camada de apresenta√ß√£o no meio.¬† Normalmente pensamos no cliente como o browser e na camada de apresenta√ß√£o como o struts/spring MVC/ JSF. Contudo sabemos bem que devido a coisas como Ajax, REST, javascript estas partes ( browser – framework web) n√£o s√£o separ√°veis. N√£o com um corte limpo.¬† Mas se pensarmos que na realidade “browser+framework web” s√£o o cliente ficamos com um camada inteira para desacoplar e manter desacoplada. O que significa muito espa√ßo de manobra. Afinal a camada de apresenta√ß√£o n√£o deve depender do cliente (camadas s√£o independentes e se B sucede a A , B n√£o pode depender de A.)

Dito de outra forma. Ou todo o mundo está violando a separação de camadas por fazer a camada de apresentação conhecer o cliente ( o que é sacrilégio já que ninguém aceitaria fazer depender o DAO do business) ou ninguém está usando a camada de apresentação de fato.  Claro que sabemos que a primeira é verdade já que todos assumimos usar duas camadas e todos assumimos que a nossa implementação web depende do browser, mas podemos pensar que afinal não estamos violando nada e usando a segunda.

Para os mais atentos deve ficar o gosto de que estamos repetindo as mesmas “a√ß√Ķes” nesta camada de apresenta√ß√£o que repetimos nos frameworks web. Bom, no estado que √© hoje sim. Afinal as responsabilidades s√£o semelhantes. Mas se pensarmos na implementa√ß√£o da camada de apresenta√ß√£o como a verdadeira implementa√ß√£o destes padr√Ķes ( view object, dispatecher, observer) e as tecnologias web como meras canaliza√ß√Ķes – meros “drivers”- , ent√£o tanto faz √† camada de apresenta√ß√£o se o usu√°rio apertou um bot√£o no browser ou uma imagem no swing (ou vice-versa) : o que interessa √© a inten√ß√£o chamada “salvar”¬† ou “calcular” etc…Afinal s√£o estas inten√ß√Ķes que o sistema entende (como no caso do REST ele s√≥ entender update, post, get, put, delete) e tanto faz , quem, como ou quanto foram chamadas.

Este design ainda n√£o responde a todas as quest√Ķes como “como populo um table a partir de uma tabela” e como mudar o struts pelo ZK, por exemplo, mas acho que abre uma porta sem realmente inventar nada e apenas vendo o que temos com outros olhos. E com essa porta come√ßar a pensar como seria a implementa√ß√£o de algo assim.

Aguardo as vossas opini√Ķes sobre o conceito e coment√°rios.

 

 

Comente

Artigos