Abraço,
Igor Takenami

O Struts é o mais popular framework MVC, sendo utilizado na maioria dos projetos WEB. O Struts representou uma grande melhoria na forma de integração entre as camadas de MODELO, VISÃO e CONTROLE. O que parecia ser uma solução para facilitar o desenvolvimento, se mostrou muito improdutivo. Sua improdutividade era decorrente da necessidade de se criar muitas classes e configurar complicados arquivos no formato XML.

Com o passar do tempo, a evolução do framework e do próprio JAVA foi inevitável. Para chegar a versão 2 o Struts uniu-se ao Webwork, outro conhecido framework. A evolução também veios em outros projetos como a especificação JSF, Open Laszlo, ThinWire, etc…

Pessoalmente, nunca gostei do Struts! Mesmo tendo IDE’s para apoiar a adoção do framework, sempre achei muito trabalhoso e pouco simples. Foi tentando manter o padrão MVC, mas sem utilizar o Struts que conheci o VRaptor.

Escrito pelo Brasileiro Guilherme de Azevedo Silveira o VRaptor é um framework MVC que utiliza recursos do JAVA 1.5 para fornecer eficiência e produtividade ao desenvolvedor. Utilizar o VRaptor para criar aplicações MVC é bastante simples, tornando a curva de aprendizado muito pequena.

O que mais atrai no framework é a facilidade para construir Actions fazendo uso das notações e o conceito de convenção ao invés de configuração (difundido pelo Ruby on Rails). Os recursos disponíveis no VRaptor permitem escrever programas utilizando MVC sem a necessidade de conhecer outras API’s como a Servlet. Para demonstrar isto vamos ver como seria uma Action escrita em Struts:

Além de todo este código, leve em consideração a criação do ActionForm e as configurações no struts-config.xml. Agora vejamos como ficaria esta mesma Action no VRaptor:



Observer que a classe é simples e manipula objetos conhecidos (não é preciso estender nada). Além de toda simplicidade, não é preciso criar ActionForms e nem configurar nenhum arquivo XML (Se você seguir a convenção é claro). Depois disto é só escrever o arquivo cliente\adicionar.sucesso.jsp e utilizar as TAGLIBS ou TAGFILES de sua preferência.

Utilizar o padrão de arquitetura MVC garante segurança para possíveis problemas que podem ocorrer na camadas de apresentação caso utilize outras tecnologias como: JSF, Laszlo ou Thinwire, pois estamos em contato direto com o código HTML. O ponto negativo é a baixa produtividade gerada por um processo que exige mais trabalho de codificar a VIEW em arquivos JSP com TAGS Java e HTML.

Grande Abraço,
Igor Takenami

A abstração é o principal motivo para o aumento da produtividade, mas também pode ser a engrenagem que “emperra” o desenvolvimento. Este é um risco deve ser bem estudado.

O cenário pode ser exemplificado da seguinte forma: Em um projeto, muito importante ,você utiliza JSF (Java Server Faces) na camada de apresentação. O IDE NetBeans lhe ajuda bastante para construir as telas de forma visual. Os componentes lhe poupam um grande trabalho pois abstraem muitos dos problemas do desenvolvimento WEB.

Com estas informações poderíamos deduzir que a utilização do JSF trouxe um significativo ganho de produtividade, mas vamos supor que no meio do projeto surge à necessidade de utilizar vários componentes que não existem. O que fazer se não sabemos como construir estes componentes? Qual a dificuldade para criar estes componentes? Existe suporte? Documentação?

Este exemplo mostra que precisamos saber o que estamos utilizando antes de se aventurar em um projeto. Quando for utilizar alguma tecnologia/especificação nova, faça testes em um projeto piloto de media/baixa importância. Isto diminui o risco de problemas em um grande projeto.

Agora que falei minha opinião sobre o assunto posso dizer que na maioria (não sempre) das vezes o mais seguro é utilizar o batido padrão MVC. O desenvolvimento “feijão com arroz” pode ser improdutivo, mas garante que um problema seja facilmente contornado. Mas fique atento, pois ao falar MVC não me refiro ao Struts (muito pelo contrário). Se você pensou desta forma, esqueça, pois este framework esta longe de ser produtivo. Isto é um assunto para o próximo POST.

Grande Abraço,
Igor Takenami

Utilizar a VCL4PHP mesmo sem o IDE da Codegear já é uma boa alternativa para facilitar o desenvolvimento. Com o tempo IDE’s abertos devem utilizar este componente aumentando a produtividade para quem desenvolve em PHP. O VCL4PHP funciona de forma bastante similar ao VCL do Delphi. Assim como no Delphi cada página possui uma Unit onde estão todos os componentes e seu comportamento. Para cada Unit existe outro arquivo PHP que contem uma estrutura XML com informações sobre as propriedades dos componentes. Estas propriedades definem: posicionamento, layout e comportamento.

É importante observar que para rodar o VCL4PHP fora do IDE da Codegear é preciso baixar os componentes e configurar o arquivo php.ini habilitando a extensão php_filter, que trata os eventos dos componentes.

Download com Exemplo Basico do VCL4PHP

Abraço,
Igor Takenami

Apesar do foco da aplicação esta na maioria das vezes na arquitetura que será utilizada (n camadas, componentes distribuídos, transação, monitores), a camada de apresentação de uma aplicação WEB é notadamente a vilã, quando estamos falando em produtividade. Isto porque por mais complexa que seja a arquitetura, com algumas definições e técnicas como MDA (Model Driven Architecture), pode ser gerada automaticamente. Seu ponto de modificação é facilmente localizado restando para o programador somente implementar a lógica do negocio.

Já a camada de apresentação é muito relativa, pois é a ponte entre o usuário do sistema e a aplicação. No caso do JAVA existem várias especificação e um conjunto de padrões de projetos destinados a tornar isto mais fácil como: JSP, MVC, JSF. Cada uma destas especificações possui uma forma muito particular de se trabalhar, mas sua contribuição esta mais associada ao desacoplamento da interface da lógica do negócio. O JSF (Java Server Faces) por ser mais moderno vai além e torna o desenvolvimento de aplicações WEB parecida com a desktop, mas por trás das cortinas ainda temos todo processo de enviar e receber grandes requisições quando queremos alterar o conteúdo de um componente visual.

Uma boa solução para este problema é utilizar AJAX e fazer requisições assíncronas colocando um pouco do processamento no cliente e evitando, por exemplo, uma requisição de página inteira para cada mudança no componente visual. Baseado neste conceito é que funciona o Thinwire. Além de trabalhar com AJAX o framework cria os objetos visuais em um arquivo .java (assim como no desktop). Com isto não é necessário nenhum conhecimento em JSP, HTML, etc…

Cada componente é um objeto e pode ser adicionado a outro fazendo composições de elementos visuais que serão renderizados no browser através de um Servlet implementado pelo framework. Além disto, o processo é bastante simples e bem semelhante ao já conhecido. Só para ter uma idéia no arquivo web.xml é preciso identificar a classe que possui o método “public static void main” que inicia a aplicação.

O Framrwork esta em versão Release Candidate e vale a pena testar. Para saber mais visite: http://www.thinwire.com

A Borland sempre foi conhecida pelo seu pioneirismo quando o negócio é disponibilizar tecnologias emergentes em seus produtos. Mas será que desta vez podemos chamar isto de inovação? Unir a produtividade do Delphi com a facilidade do PHP é bastante tentador, mas a esta altura do campeonato será que ainda temos mercado para isto? É certo que a maioria dos projetos Open Source WEB são em PHP, mas ao que tudo indica o IDE será pago afastando esta possibilidade para popularizar o produto.

Às vezes me pergunto se não seria tarde para um IDE proprietário entrar no mercado tentando facilitar o desenvolvimento de uma linguagem que já é uma das mais produtivas. Uma coisa é certa: Borland é Borland e já me surpreendi muito com a qualidade de seus produtos. Acho que o mercado de IDE proprietária ficou no passado e a maior contribuição que pode ser feita é realmente liberar o código para projetos Open Source. A própria comunidade deveria ser responsável por evoluir a suite ajudando a própria Borland a popularizar seus outros produtos que funcionariam integrados a esta suíte. As respostas para tantas dúvidas, só o tempo pode responder. Vamos aguarda o lançamento do novo IDE.

Para saber mais:
http://dn.codegear.com/article/34059 http://www.codegear.com/Products/Delphi/DelphiforPHP/tabid/237/Default.aspx

Mais importante que a Linguagem Ruby e o Framework Rails (Ruby on Rails), é o barulho que isto vem causando no mundo. O movimento vem fazendo com que arquitetos de software e programadores de todo o mundo repensem os conceitos por trás da WEB e a melhor forma de extrair resultados positivos. Este movimento ganhou uma grande quantidade de seguidores depois que a 37signal (http://www.37signals.com/), empresa que criou o Basecamp e conseqüentemente o Rails, lançou o livro: Getting Real (Caindo na Real). O livro esta disponível gratuitamente e em português pode ser lido no endereço http://gettingreal.37signals.com/GR_por.php. Suas páginas questionam vários fatores de sucesso para o desenvolvimento de aplicações WEB e satisfação dos usuários.

Sem dúvida todo este movimento vem sendo impulsionado principalmente pela WEB 2 e pela demanda de aplicações que sigam este modelo, mas uma coisa é certo: “A cada dia que passa, construímos aplicações mais complexas que demandam muito tempo e dinheiro para ficarem prontas”. Muitas vezes construímos um canhão para matar uma mosca. Será que Rails não é UMA solução para isto ??? Será que isto não é passageiro ou será que estamos diante de uma nova linguagem de programação que pode ameaçar o JAVA e toda a sua plataforma ??? As respostas para estas e outras perguntas que temos na cabeça só o tempo poderá dizer, o importante é ficar por dentro e acompanhar este movimento. Certamente podemos tirar muitas lições disto tudo.