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
Focou nos pontos certos!
Evitar usar soluções obsoletas para as demandas atuais e o mais importante, não refazer o que já existe de melhor.
O primeiro problema é resultado direto do medo da mudança. Claro que entram questões como padronização e outras desculpas, mas o medo prevalece.
Com relação ao segundo problema, grande parte da culpa é política e não técnica. Provavelmente, o sujeito influente toma decisões baseado em “achismos” e leva toda a instituição pública (ou privada) a adotar a liberdade da plataforma Java, mas preso pela absurda idéia de “isso não foi homologado aqui” ou não temos o suporte da empresa X. Como conseqüência, um framework caseiro aparece feito às pressas.
Ora veja, se vão fazer dentro de casa algo que existe no mercado (e ainda open-source), porque não adotá-lo se há a necessidade? Se o projeto open-source morrer, você ainda não vai ter um código bem melhor que o seu?! E mais, se o projeto open-source não servir mais, provavelmente, seu framework caseiro também não.
Vou ficar por aqui, apesar desse post estimular uma boa conversa.
@Tarso
O detalhe exposto no quarto parágrafo é importantíssimo e caiu como uma luva.
Realmente alguns dos principais problemas se dá por conta das más escolhas, da política da empresa.
Bem, vamos por partes como já diria o saudoso “Jack The Ripper”
A pergunta que originou o Post não é tão simples, Struts e JSF representam dois estilos bem diferentes, um Action-based e o outro Component-based.
Não defendo bala de prata e detesto o Struts, mas action-based é mais apropriado para desenvolvimento web, vide o sucesso do rails. Outra coisa que me incomoda é dizer que JSF tem menos artefatos, isso não é absolutamente verdade, apesar de struts tender a uma estrututa BOLOVO eu posso desenvolver de forma diferente.
O problema do struts 1.x- não é o paradigma action-based e sim sua arquitetura que era ridícula. Outro ponto que discordo é diminuir as críticas porque ganhamos dinheiro com Struts e portanto não podemos falar dele. Struts era uma merda, e está totalmente ultrapassado.
JSF foi feito não pensando em desenvolvimento web mas até via telnet (existe componentes para ftp, telnet, etc) o que não é realidade como sempre as JSRs fazem, vide o padrão JDO vs Hibernate onde o mercado venceu um padrão pelo simples fato que banco de dados é praticamente o único mecanismo de persistencia usado no mercado.
Então respondendo a pergunta, não existe escolha antecipada de frameworks, quem escolhe um framework antes de iniciar um projeto é amador ou irresponsável, já fiz isso antes e vejo gente fazendo ainda hoje.
Depois que voce inicia o processo de desenvolvimento muitos questionamentos são feitos, quem faz um sistema pensando em JSF ou Struts estará direcionando o sistema para a natureza desses frameworks quando deveria ser o oposto. Por isso o Struts tende a BOLOVO, porque as pessoas desenvolvem um sistema para se adequar ao Framework, quando deveria ser o inverso.
Já vi gente tentando adaptar um sistema ao Hibernate, geralmente isso causa uma arquitetura relacional em java ao inves de OO, isso é comum demais. Ao inves de usar o hiba como mapeamento entre os dois mundos, o cara desenvolve pensando como agradar os relacionamentos.
Quanto ao fato dos frameworks caseiros, devem ser processados aqueles que prejudicam um projeto por caprichos idiotas. Exemplifiquei em vários posts porque fazer e não fazer um framework caseiro.
Tenho exposto minhas idéias a esse respeito na lista do CEJUG. Acho totalmente inapropriado a adoção de frameworks caseiros, sejam eles quais forem. Eu adotei o Struts a 4 anos atrás e hoje choro pelos cantos arrependido. Mas não tinha jeito, não havia outra opção a altura. O refactoring terá que ser feito de qualquer forma.
Vou esperar pelo JavaFX antes de debandar para o JSF. Mas projetos novos deveriam adotar JSF, mesmo que isso implique em treinar a equipe. Se todos os meus funcionários (nenhum no momento) soubessem struts e eu fosse começar um novo projeto, faria um baita curso de JSF para diminuir os riscos da sua adoção, porque no futuro, não vou encontrar profissionais suficientes com conhecimentos em struts para manter o projeto. Os que eu conseguir vão dizer: “Struts?! Me desmotiva, tô fora!!”. A adoção de um framework depende de um planejamento a longo prazo. Não é uma coisa de momento.
Bem acho que o Milfont já falou tudo, mas quero se é que é possível adicionar mais alguns comentários.
“A criação de uma classe Java que estende a classe ActionForm (Struts)”
Isso até mesmo antes de sair a versão 1.2 já foi resolvido, e com uma solução bastante simples, não se faz necessário utilizar o FormBean ou ActionForm como queira chamar, você poderia ter um único ActionForm, um DefaultForm, que nada mais é do que um HashMap com seu get e set. Isso já mata muita coisa.
“criação de um XML denominado struts-config.xml
configuração do ActionForm no struts-config.xml
configuração da Action no struts-config.xml”
Sei pouco sobre JSF mas creio que você tambem configura, seja com XML que odeio, ou com Annotations que eu particularmente não gosto de utilizar por ser muito intrusiva nas classes. Então não justifica tanto isso.
“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.”
Putz, ele vem praticamente com CommonsValidator da apache embutido O_o.
Essas observações são do Struts 1.x, o Struts 2.0 ele deixa sua aplicação independente da action, você não precisa mais estender nada para utilizar a action(herdada do webwork), no Struts 2 a validação já vem mais que embutida, e de quebra a parte de Ajax é com o DWR já embutido com tags se desejar. Você já utilizou o Struts 2 ? Eu nunca utilizei a sério, em projetos pois não tive chance, mas tenho vontade, pois já fiz alguns testes com ele e achei fantástico, claro que não conta muito, pois só vale aqueles onde temos que testar no dia a dia, com todos os pepinos e etc…mas já deu para dar uma nosção.
Tenho um sistema rodando que utiliza as chamadas “10 Melhores práticas com Struts 1.x”, link(http://www.javaworld.com/javaworld/jw-09-2004/jw-0913-struts.html) que facilita bastante o desenvolvimento, e estamos utilizando POJO, nada de BOLOVO, então acho que é complicado você falar isso, pois depende muito de quem implementa, claro, as vezes o framework te deixa meio que preso a “solução” dele, mas que podem ser dribladas(dribladas!= gambiarras)para melhorar a produtividade, NÃO EXISTE BALA DE PRATA.
Agora como o Milfont falou…
“Outra coisa que me incomoda é dizer que JSF tem menos artefatos, isso não é absolutamente verdade, apesar de struts tender a uma estrututa BOLOVO eu posso desenvolver de forma diferente.”
“eu posso desenvolver de forma diferente.”
A mais pura verdade, e tenho código para provar se quiser da uma olhada ;D
Na minha humilde visão, não adianta utilizar JSF, Struts ou qualquer outro que diz ser a solução dos problemas, se quem vai implementar fizer merda.
Abraços.
Excelente post Carneiro!
Ao se iniciar um novo projeto muitos desenvolvedores “sênior” ou “arquitetos-megalomâniacos” já pensam na arquitetura da aplicação antes mesmo de conhecerem o problema do cliente! E pior, esquecem que arquitetura tem a ver com pessoas, não com frameworks. Qual o melhor framework MVC para utilizar neste projeto? Não sei, quem decide isso é a equipe como um todo.
A idéia do Struts é boa, o problema é que ela foi mal implementada, talvez pela época, não sei, mesmo assim é possível desenvolver aplicações com Struts 1.x de maneira decente e simples, o difícil é encontrar gente capacitada para isso. JSF em si é muito mais simples de aprender e manter, principalmente por desenvolvedores que vêm do Swing (eca!). Contudo ainda vejo muitos projetos em JSF mal arquitetados, JSF é para ser simples, ele é simples, porém ainda assim conseguem embutir complexidade no projeto!
Engraçado, em 2005 já se comentava o problema de frameworks caseiros, mas hoje no ano da graça de 2008 (como sempre diz o Milfont) tem empresas fazendo isso, e pior, instituições públicas!
Mais importante que investir em frameworks caseiros é investir em pessoas, na equipe. Uma equipe capacitada desenvolverá uma solução adequada para o problema do cliente, ele saberá quais as ferramentas, metodologias e frameworks para determinado problema.
Enfim, post bacana Carneiro, espero que este post abra os olhos de várias pessoas.
@Rafael Ponte
Na época que o Struts foi lançado ele surgiu com irreverência, era diferente e novo. Para a aquela época ele serviu, mas hoje em dia ele não serve mais, lembrando que no post me referi somente as versões 1.x do Struts, deixando assim as versões 2.x de lado.
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. Rafael, conheço um pouco de struts, mas não de jsf, esse paragrafo acima se refere as desvantagens do JSF? No mais gostei muito do artigo e como estou começando fiquei confuso em qual escolher. Talvez seja mais fácil para vocês que tem mais vivência e experiência com tudo isso. Em suma gostei muito do tópico.
@Paulo Marcelo
Me referi as versões 1.x do Struts.
O Vraptor é o framework que tem na apostila da caelum? Você sabe dizer se ele é muito utilizado nas empresas?
@Paulo Marcelo
Sim, é esse mesmo. Ele vem sendo utilizado em muitas empresas, mas não sei te informar os números. Consulte o site do VRaptor (www.vraptor.org) para obter essas informações.
@Paulo Marcelo
No ano da graça de 2008 não vale a pena investir em Struts 1.x, mesmo que a maioria dos desenvolvedores do mercado o conheçam bem. Escolher um framework tem muito a ver com a equipe de profissionais engajada no projeto, e o problema do cliente claro.
Atualmente JSF está sendo o framework MVC Java mais adotado em novos projetos, por vários motivos e claro, por sua simplicidade.
VRaptor é uma excelente solução também, ele é bem simples, talvez até mais simples que JSF por trabalhar em cima de convenções.
Se realmente quiser Struts, vá de Struts 2.x. O Struts 1.x é passado, hoje é simplesmente legado que será mantido por mais alguns anos.
[...] uma vez por toda que não existe uma arquitetura de referência ou receita de bolo para desenvolver sistemas, cada sistema possui suas necessidades e peculiaridades, e estas devem [...]
[...] Pior do que usar um dos dois frameworks citados acima é criar seu próprio mini-fashion-templating-framework, seja utilizando-se de JSP taglibs ou mesmo de um Servlet Filter, não importa, fuja disso, evite reinventar a roda, aliás, evite reinventar uma roda ainda pior do que as já existentes [não quero entrar na discussão dos malefícios de criar seu framework caseiro]. [...]
Sou Java de carteirinha mas preciso dizer isso: É por isso que .NET avança. Enquanto nossas cabeças no java se debatem x, y e z dos frameworks, vem a M$, impõe a sua lib, todo mundo gosta e os gerentes mudam pra ela…., e a gente tem que engulir… Eu sempre disse pra minha mulher: Quanto tem muita opção a gente se confunde (experimentem um dia fazer uma reforma na sua casa….)