Um pouco de conversa
Sempre que posso, acesso o fórum do Javaranch para ver as novidades e assuntos interessantes do mundo Java. No feriado de ontem estava eu navegando nesse fórum quando achei um tópico de título “When to use JSF or Struts“. Título este bem chamativo, por conta das diversas discussões e comparativos sobre esses frameworks na comunidade Java do mundo inteiro.
Nesse post, o autor pergunta qual a diferença entre os dois. A diferença é simples: a quantidade de artefatos criados e a complexidade de sua utilização. JSF é bem simples e com algumas configurações e artefatos criados já está apto para ser utilizado no seu sistema. Eu não sou xiita e não estou dizendo que JSF é melhor do que Struts ou qualquer outro framework, não estou afirmando que ele é a bala de prata. E não é.
Gostei muito de uma resposta desse post e ainda bem que ela foi logo a primeira resposta, evitando que outras respostas mudassem os pensamentos e opiniões dos leitores. Nessa resposta, o autor enfatiza: “How to choose? For me, I’ll choose a framework that team members familiar with“. Essa resposta foi bem coerente, pois se sua equipe possui experiência e produtividade com o framework X, não quer dizer que se adotar o framework Y aumentará a produtividade da equipe, pelo contrário, pode acontecer o inverso, já presenciei casos desse tipo.
É comum ver em fóruns, listas de discussão e até mesmo no dia-a-dia, profissionais discutindo com seus companheiros de trabalho, alegando que o Struts (versões 1.x) é obsoleto e está ultrapassado. Isso não é mentira, é fato. Porém o que não concordo é esse xiitismo e essa generalização em volta desse assunto. Você já trabalhou com Struts, já ganhou muito dinheiro com ele, eu também. O framework Struts foi por muito tempo o framework padrão de mercado, exigido por quase todas as empresas como requisito fundamental no currículo. Acredito que apenas uma fatia dos novos desenvolvedores que iniciaram a pouco tempo não tiveram a chance de trabalhar com ele. Mas este dia chegará, pois muito em breve esses teenagers irão prestar consultoria em sistemas que foram feitos com esse framework.
Por que o Struts está obsoleto?
É muito simples de explicar. Veja a imagem abaixo e tente comparar com qualquer outro framework da moda.
Essa arquitetura é completamente orientada a BOLOVO. Note que é necessário a criação de vários artefados para a criação de um simples caso de uso.
Artefatos necessários:
- configuração do Servlet Front Controller do Struts no deployment descriptor (web.xml)
- criação de um XML denominado struts-config.xml
- criação de uma classe Java que estende a classe ActionForm (Struts)
- criação de uma classe Java que estende a classe Action (Struts)
- configuração do ActionForm no struts-config.xml
- configuração da Action no struts-config.xml
- se você for utilizar validação (que é necessária em todo sistema que se preze), é necessário a criação de outros artefados, como por exemplo um arquivo de propriedades.
Isso não acontece com frameworks da moda, nos quais são orientados a POJO. Por exemplo, o JSF necessita apenas da criação de uma classe POJO, configuração do Servlet no deployment descriptor e da criação de um XML chamado faces-config.xml. Três artefatos criados, eu disse apenas três artefatos criados.
Portanto, a sua utilização poderá acarretar em futuros problemas, como inúmeras refatorações. Também existe uma má utilização dos princípios da Orientação a Objetos e péssimas práticas de desenvolvimento de software, nos quais posso citar algumas: alto acoplamento, alta manutenabilidade e complexidade.
E agora, o que utilizar?
Muita calma nesta hora. Como mencionei acima, não sou xiita (a-rá, gosto de EJB e irei utilizá-lo em todos os meus projetos, até um hello world numa simples JSP, criarei diversos artefatos, farei várias configurações e utilizarei um servidor de aplicações parrudo). Ratificando: o intuito deste post não é mostrar que o framework X é melhor do que o framework Y.
Java está se tornando uma plataforma difícil de se dominar, por ser bastante abrangente e surgir novas funcionalidades todos os dias. Sem falar de frameworks, que todo dia nasce um no quarto de um desenvolvedor que está com seu ócio criativo em alta. Mas alguns frameworks estão me chamando bastante atenção, por serem produtivos, robustos e simples. São eles: JSF, VRaptor e Spring.
Lembrando mais uma vez: nenhum framework é a bala de prata!
Outros frameworks que estão chamando atenção da comunidade: Apache Wicket e Waffle. Implementações: Jersey e Metro.
Sobre frameworks caseiros
Se você acessar os maiores fórums brasileiros de Java como GUJ e PortalJava, verá inúmeras discussões sobre as vantagens e desvantagens de frameworks caseiros. Particularmente eu vejo muitas desvantagens, pois já passei por uma experiência que não me agradou muito. Há uma discussão no GUJ sobre esse assunto, ela é datada de 2005, que me chamou bastante atenção. Se em 2005 alguns dos membros mais ativos da comunida Java já falaram das desvantagens de construir tal geringonça, por que após três anos isso ainda continua?
Frameworks caseiros não são arquiteturas de referência, não são padronizados, não possuem uma comunidade em volta para dar apoio e não são padrões da insdústria de software. Construir frameworks caseiros com o dinheiro público é o pior caso de todos.
Nesse post do GUJ, Carlos Villela comentou:
Desenvolver um framework ANTES de desenvolver uma aplicacao nao da certo: ou voce acaba com a aplicacao tendo que fazer gambiarras em cima do framework, ou a aplicacao nao sai ate mudarem o framework. Eh melhor fazer uma aplicacao primeiro, refatorar ela e tirar os pedacos genericos e transformar num framework do que tentar advinhar o que eh generico e o que nao eh. Alias, risque a palavra advinhar do dicionario.
Ele adivinhou o que poderia acontecer utilizando essa abordagem e eu tive a péssima experiência de passar por isso.
Não sendo xiita, afirmo que cada caso é um caso. Está certo que em determinados projetos é necessário construir um determinado número de classes que executam processos comuns entre sistemas. Mas é para ser feito só o básico e o necessário, nada mais além do que isso, porque senão irá virar um framework!
Referências
- Entendendo Domain Driven Design, por Rafael Ponte
- Comparing Web Framework, por Matt Raible
CEJUG, 
PHP? Por que? (risos irônicos…)
O maior evento do 
