Espelho meu, qual √© melhor View que eu 

Apr/12
25

Atualmente ando preparando alguns novos projetos web. A primeira d√ļvida que surge hoje em dia √© qual tipo de visualiza√ß√£o usar, e por conseguinte qual tecnologia Java usar. Tendo em vista o futuro promissor do HTML 5 – que embora eu tenha duvida que ir√° vingar no mundo corporativo, n√£o tenho duvidas que vingar√° na internet publica – e o desalento dos criadores de browsers em boicotar o uso de plugins (a cria√ß√£o matou o criador) nos quais se inclui o Java.

Portanto pese embora o esfor√ßo da Sun e depois da Oracle em empurrar o¬† JavaFX como alternativa visual para o java substituindo em cada plataforma a forma nativa de UI e UX (user experience) o tempo e a concorrencia parecem ter ganho a batalha inicial. O JavaFX perdeu no campo dos celulares e tabblets¬† para o Android¬† e foi proibido no iPhone e iPad. Na Web perdeu para o HTML 5 e no desktop … bom, quem usar desktop em java , afinal ?

O JavaFX foi criado para competir com o Flash e o Silverlight. Mas a Revolta dos Plugins iniciada pela Apple e seguida pela Mozilla e agora pela Microsoft em proibir o uso de plugins em browsers e suportar HTML 5 em vez, matou o Flash e o Silverlight antes sequer do FX vingar como competidor nesse campo. √Č como se o campo de batalha tivesse sido removido e o Fx chega todo armado at√© aos dentes para encontrar um v√°cuo onde nada existe mais. A alternativa √© ainda vender o FX para celulares e o JME 3 com equipara√ß√£o JSE 7 (uau!) e com isso criar aplicativos iguais ou melhores que os dos android ou iphone. No andoid a gerra esta perdida, quanto a mim, mas no mundo do iphone ainda ha esperan√ßa de vermos um compilador nativo que¬† compila um jar junto com a JVM e joga tudo em formato bin√°rio indistingu√≠vel daquele que o¬† SDK da Apple gera. No desktop poder√≠amos ver o uso do JWS para difundir novos aplicativos RIA. Com o projeto jigsaw do java 8 isto √© ainda √© uma possibilidade real para aplicativos, sobretudo se o JWS poder ser instalado via os¬† Markets da vida seria uma forma, quase viral, de trazer o java de volta tanto no mercado corporativo como no mercado publico.¬† O JWS √© de fato o av√ī do conceito de Market, e hoje que todo mundo entende o conceito seria muitos mais simples vender o conceito de aplica√ß√Ķes instal√°veis remotamente. Os novos applets seriam servidos por Markets e n√£o por simples Browsers.

A promessa de um cross-compiler de javaFX para HTML 5 seria a opção matadora e a arquitetura do Fx 2 parece levar isto em consideração. Mas quando poderemos ver isso em produção e será mesmo que vai acontecer ? Estas duvidas tolham o processo de escolha.

Pessoalmente adoro trabalhar com Swing e acho  cem vezes mais produtivo do que qualquer coisa baseada em request-response. Portanto o Fx vem mesmo em boa hora. Mas é o futuro ?

Por outro lado, temos coisas com o Play Framework  que já prometer um novo mundo de programa em Java (ou scala) e corra onde quiser. Baseado em GWT e no compilador java-javascript a magia está pronta para acontecer. Mas e o vendor lock-in ?

O mesmo acontece com frameworks como o Wicket e o Vaadin que embora n√£o prometam a integra√ß√£o HTML5 conseguem-se aproveitar dessa tecnologia e o programador apenas programa em Java (bom o Wicket ainda exige criar as p√°ginas em HTML o que eu acho desproposital). As UI s√£o swing-like e a UX √© a de um aplicativo desktop. N√£o s√£o tecnologia para usar em uma loja virtual, mas para sistema corporativos parecem bem decentes. Mais um vez, o problema do Vendor Lock -in aparece como um contra. Nem sempre as decis√Ķes arquiteturais dos criadores v√£o de encontro √†s necessidades e podemos assistir a um Struts novamente (sendo abandonado pelo seu primo Struts 2).

Se o Struts no ensinou algo é que não podemos abraçar a tecnologia emergente sem pensar nas consequências.  ninguém previu o abandono do Struts, cegos com a novidade as pessoas escolheram não ver os problemas arquiteturais que o Struts tinha. Relegado ao esquecimento e proibido de usar pelos seus próprios criadores na Apache que decidiram correr para o Struts 2. O mesmo aconteceu com o JSF 1.0 que foi modificado em tantas coisas para se transformar no JSF 2 ( quase tanto como o Fx 1 foi modificado para o Fx2). Nos dá a impressão que ainda não chegamos em um nível de maturidade  em frameworks web, mas está claro que frameworks request-response não dão conta do recado em ambiente corporativo onde ha necessidade forte de lidar com inputs e os writes são quase tantos quantos os reads.

Então, espelho meu, qual é a melhor view que eu ?

O Struts está acabado e qualquer um é melhor que ele. Os frameworks request-response são quase iguais em todos os aspetos, com o Spring MVC correndo na frente apenas porque integra o spring nativamente ( para os outros os spring é uma biblioteca de apoio e nao o core).  Estes frameworks nos dão o controle, mas não a view. Ai vem o JSP ou frameworks de formatação com o Freemarker e o Velocity. Bah! é tudo igual. Não ha componentes poderosos. Temos que os criar. Provavelmente em JQuery e usando alguma integração jquery-java muito louca.

Tiles, Sitemesh¬† e semelhantes n√£o s√£o frameworks de componentes e sim de template web. Utils para reorganizar o layout, mas in√ļteis para criar componentes ( n√£o que n√£o seja poss√≠vel, mas ningu√©m faz isso)

Bom, parece que a cada uma que coloquemos diante do espelho, sempre existir√° alguma melhor. O que fazer ?

A resposta √© realmente simples, mas normalmente descartada facilmente pelos desenvolvedores.¬† A resposta √© isolar a view. Afinal √© um andar diferente na arquitetura e deve ser tratado como tal. Acontece que n√£o √© assim que as aplica√ß√Ķes s√£o desenvolvidas. Quantas aplica√ß√Ķes voc√™ conhece ou fez em que pode mudar de struts para JSF e n√£o perder as logicas de negocio ? Afinal, os programadores insistem em programar l√≥gicas nas actions do struts ou nos managed beans do JSF, certo ? Como migrar isso. Imposs√≠vel.

Este problema adv√©m do mau entendimento e uso do padr√£o Bridge (tamb√©m chamado Mediator). Este padr√£o √© muito √ļtil e a prova dele est√° na JDBC que √© implementada com esse padr√£o. A ideia √© que voc√™ tem duas partes do sistema A e B em que ambas podem evoluir independentemente uma da outra e sem causar altera√ß√Ķes ou recompila√ß√Ķes na outra. O design disto n√£o √© trivial e por isso mesmo seria ideal que um framework existisse que provesse esta arquitetura, e √© deste santo graal que estamos √† espera.

À priori todos concordam que não faz sentido mudar ou cria mais código em business para suportar uma tela que migrou para ajax. Se ela mudar para HTML 5 temos que mudar de novo ? e para JSF ? ou para FX ? Afinal o business depende da view ? Em tese não. Não prática sim, na avassaladora maioria dos casos. E é aqui está o custo de migração. E porque o custo de migração é alto a escolha prévia da tecnologia implica num alto risco.

A solu√ß√£o ent√£o √© seguir a m√°xima da arquitetura moderna : deixe suas op√ß√Ķes abertas. E a forma de testar se isso √© verdade √© implementar pelo menos 3 clientes diferentes para o seu andar de apresenta√ß√£o e usar o mesmo business para cada um.¬† Isto √© o futuro. Porque assim, n√£o importa qual a view que usar nem como os browsers v√£o evoluir, a sua aplica√ß√£o ainda far√° o mesmo.

Por outro lado, mudar de view √© o que diferencia as vers√£o de um software. Portanto, comercialmente √© interessante evoluir a view a gosto da moda, mas financeiramente n√£o √© interessante reescrever as regras de neg√≥cio cada vez que fazemos isso. A √ļnica forma √© portanto utilizar o padr√£o Bridge, isolar a view do resto e escolher a view do momento.

Fácil ? Não é fácil. Mas se fosse, qual seria o desafio ?

Curiosamente, todo sabem que esta √© a resposta certa, mas rapidamente ela √© descreditada com frases feitas como “N√£o temos tempo agora” , “N√£o est√° no escopo” , “N√£o temos or√ßamento” … t√°. Mas temos or√ßamento para bancar os custos de manuten√ß√£o em tecnologia obsoletas, e refazer a mesma coisa N vezes …

Esta d√ļvida sobre qual view √© melhor n√£o adv√©m apenas da necessidade de escolhas para novos sistemas, mas tamb√©m como d√ļvida sobre qual tipo de framework de view prover no MiddleHeaven. Por enquanto temos o feij√£o-com-arroz do JSP ou Freemarker, mas como disse isto n√£o prov√™ componentes nem manuten√ß√£o f√°cil no futuro. A ideia de um padr√£o Bridge parece ser a √ļnica que faz sentido aqui , mas √© muito f√°cil. O padr√£o de programa√ß√£o visual √© Event Driven como o Swing, n√£o importa como mascaremos isto, isto √© o que queremos realmente usar.

Seria interessante ter o vosso feedback do que estão usando, prós e contras e se concordam que isolar a view é a forma segura de prosseguir.

 

 

 

 

 

3 comentários para “Espelho meu, qual √© melhor View que eu”

  1. Interessante seu post. Não faço ideia como poderia ter um isolamento fácil assim para que um tecnologia de view fosse trocada por outra. Talvez nem seja possível.

  2. √≥timo post como sempre S√©rgio. Esta vis√£o √© fundamental para que possamos construir Softwares mais flexiveis. Dificil realmente √© ver quem se utiliza de uma vis√£o assim, pois na maioria das vezes o Controller de uma framework web √© tido como o lugar onde voc√™ coloca suas regras de neg√≥cio e a hist√≥ria de separa√ß√£o de camadas vai pra longe. Interessante tamb√©m √© o ponto onde voc√™ prop√Ķe construir Views distintas para atestar o uso de um ponto central de regras de neg√≥cio no software, por√©m nunca vi ningu√©m fazer isto na pr√°tica.

  3. O fato de não se ver fazer não sei se é pelo custo ou pelo desconhecimento de quem faz (ou deveria fazer). Isso que vc falou de que o controller do framework web é tido como esse objeto de ligação é fato. Mas se o controller é do framework, acho que é óbvio que não será reaproveitável ( por exemplo, o action do stuts não serve no JSF, nem no Spring MVC que é uma tecnologia semelhante em temos de conceito de fluxo).
    Antigamente, na √©poca do j2EE hardcore quando se usavam DAO e ServiceLocator tinha um cara que poderia ser usado para isto : Business Delegate. O Business Delegate √© como um emissario da camada de business que cont√©m regras de negocio mas n√£o de view. Por exemplo, em vez de chamar o SessionBean, chamava-se o Business Delegate para realizar alguma a√ß√£o. Quando se usava apenas como um fa√ßade para o session, realmente n√£o tem vantagem, o ideal √© quando ha alguma logica no BD que n√£o existe ou n√£o precisa existir no servidor (como um calculo simples em cima de um array ou lista. Por qu√™ passar a lista para o servidor s√≥ para fazer isto ?) Mas ainda temos o problema do fluxo da view. Por exemplo :”ap√≥s salvar um novo produto v√° para a lista de produtos”. Este tipo de UC √© simples, mas a implementa√ß√£o n√£o √© reaproveit√°vel. Acho que o jeito seria mesmo o padr√£o Bridge ( ou o padr√£o Mediator), mas ainda n√£o sei bem …

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos