Ultimamente tenho visto nos fóruns e blogs pelo mundo comentários inflamados sobre Struts em comparação com outros “MVC web application frameworks”, como o Webwork.
Trabalho com o Struts e acho que ele é uma mão na roda, mas eu queria saber em poucas palavras em que o Webwork é definitivamente melhor do que o struts, sem “hype marketing”.
PS.: Eu já lí esta comparação:
Em menos palavras do que isso não dá: WebWork é mais simples.
ok, já é muita coisa 
o cv falou o q era preciso
vc nao precisa ler um livro de webwork para fazer o q quer fazer com ele.
a forma que o webwork é utilizado é MAIS NATURAL que o struts… a lógica, o funcionamento.
ainda tenho meus preconceitos contra webwork tambem pq peguei versoes com muito bugs, mas isso já é apelo pessoal.
creio que hoje em dia no brasil struts só serve para arranjar emprego e espero que isso não fique muito tempo assim.
soh aquela assinatura gigante de metodo que as action tem de implementar da arrepio. ficar passando request, response e mais um monte de coisa pra tudo que eh lado eh no minimo estranho, sem contar que voce nao esta trabalhando nem estaticamente, nem orientado a objeto, esta TUDO orientado a request, quase thread local
a verdade é que vc escreve menos código.
(obs: trabalho com Struts a quase de 1,5 anos 
)
menos código com o struts??
como?? (ou entendi errado o que vc quiz dizer??)
[quote=“urubatan”]menos código com o struts??
como?? (ou entendi errado o que vc quiz dizer??)[/quote]
eu me expressei mau . Menos código com o WebWork.
Em relacao a grande assinatura dos metodos no struts, isso se deve ao fato de ele seguir a orientacao de servlets, de nao utilizar atributos de objetos para armazenar essas informacoes.
Isto quer dizer que somente uma instancia do Action pode tratar todas as requisicoes desse action no container.
Nao conheco muito o WebWorks, mas parece que cada requisicao implica na criacao (ou uso de pool) de instancias do action. Dependendo da complexidade esse cria/destroi pode vir a ser um problema de performance, por sucessivas chamadas do GC. Obvio que hoje em dia as JVM estao muito boas nesse sentido, mas eh uma linha diferente que o Struts segue, de ser mais proximo ao modelo de servlet, e nao acho justo crucifica-lo por isso.
Acredito que existe espaco para os dois Frameworks no mercado. O fato que mesmo com suas limitacoes, o Struts virou um padrao de mercado, sendo usado como base ate pela Oracle. Hoje em dia conhecer struts, no minimo, eh interessante, ate por causa do grande numero de aplicacoes usando ele e seus derivados.
Eu acho perfeitamente justo crucificar o Struts por ter tomado uma decisao de design baseada em dados de performance que nem sequer existiam. Numa requisiçãozinha qualquer, o seu Servlet container já cria objetos adoidado, e não vai ser um mero new a mais ou a menos que vai fazer muita diferença. Isso é crucial no caso de um framework como esses, já que o fato de o Struts evitar criar novas instâncias das Actions trouxe a maior parte da complexidade dele (ActionForms, FormBeans e tudo mais), que é absolutamente desnecessária (e o WebWork prova).
E é WebWork, não WebWorks.
IMHO o motivo pelo qual o struts virou um padrão de mercado, é que até pouco tempo atraz, não existiam outras opções a altura,
e este é o mesmo motivo pelo qual o struts não evoluiu muito também, des da primeira versão do struts, muito pouco foi adicionado ao core do struts, ele continua basicamente a mesma coisa.
Acho que o struts é um projeto que deveria ser mantido apenas para dar suporte aos projetos ja existentes, e ser desenvolvido um “struts 2.0” a partir do nada, e sem muitas preocupações com compatibilidade ou alguma coisa do genero.
se bem que parece que o “dono” do struts, também acha isto, tanto que ele esta no expert group da JSF e quer para as novas versões da JSF integrar as funcionalidades de MVC na especificação para matar a necessidade do struts 
[quote=“cv”]
Eu acho perfeitamente justo crucificar o Struts por ter tomado uma decisao de design baseada em dados de performance que nem sequer existiam. Numa requisiçãozinha qualquer, o seu Servlet container já cria objetos adoidado, e não vai ser um mero new a mais ou a menos que vai fazer muita diferença. Isso é crucial no caso de um framework como esses, já que o fato de o Struts evitar criar novas instâncias das Actions trouxe a maior parte da complexidade dele (ActionForms, FormBeans e tudo mais), que é absolutamente desnecessária (e o WebWork prova).
E é WebWork, não WebWorks. :D[/quote]
Bem esta eh a SUA opiniao. O fato de voce ler a pagina de comparativo entre Webwork(obrigado pela correcao) e Struts nao implica que tudo esta certo. Eh uma visao unilateral e cada um quer vender seu peixe.
O fato eh que os objetos criados pelo container, como Request, por exemplo sao simples, com pouca informacao. Alem disso, o Servlet Conteiner pode tranquilmanete fazer pool desses objetos evitando criacao desnecessaria. Agora o custo de criacao de um Action do WebWork, eu nao sei qual é. Sei la, vai que um maluco manda criar um array de 10 mega no contrutor do action. Bem , no struts isso nao tem problema (muito grave) ja que isso sera feito uma vez soh.
Mas realmente voce tem razao em falar que o Struts possui um design um pouco antiquado, nao ha duvida disso. Na verdade o que mais me irrita no Struts eh a obrigatoriedade de ter que derivar das classes dele( ou seria um problema do java nao ter heranca multipla ).
nao vamos tirar os métodos do Struts :-), ele foi o pioneiro e salvou a vida de muitos já.
O Mike Tyson “foi” o campeao mundial já, hoje não é mais. Mas alguem vai dizer que o cara não é bom de briga? Ele apenas não é mais o melhor.
.
Ninguem pode negar que o Struts agiliza o desenvolvimento MVC. Se o WW é melhor é outra coisa, o Struts continua com todos os seus méritos.
disse tudo ai.
tanque, objetos como o Request criado pelo Tomcat nao sao leves, pelo contraruio, sao muito mais “pesados” que objetos de logica de negocios, as actionss no caso. Um mero newInstance eh algo que sai de graca! ficar com um objeto soh para as acoes na memoria implica em ter de pensar em thread safety, alem de voce passar a trabalhar nao orientado a obnjetos: aquilo vira uma funcao.
[quote=“Guilherme Silveira”]
disse tudo ai.
tanque, objetos como o Request criado pelo Tomcat nao sao leves, pelo contraruio, sao muito mais “pesados” que objetos de logica de negocios, as actionss no caso. Um mero newInstance eh algo que sai de graca! ficar com um objeto soh para as acoes na memoria implica em ter de pensar em thread safety, alem de voce passar a trabalhar nao orientado a obnjetos: aquilo vira uma funcao.[/quote]
Bem, os Request ate podem ser pesados, ocuparem memoria. Mas, eu nao tenho como fugir deles, a nao ser que eu abandone java, ou servlets e jsp ao menos.
Mas o grande diferencial ai eh que eu tenho liberdade de escolha. Nao estou contente do jeito que o tomcat trata as requisicoes, posso mudar para o weblogic, para o jetty, resin, qualquer web container.
Agora se eu ficar descontente com o struts, ou o wework, nao tem jeito. Tenho que reescrever minha aplicacao. Nao posso simplesmente trocar de fornecedor. Se por acaso o fato do webwork criar sempre os actions, num futuro teste de performance, se mostrar inviavel (acredito que nao o sera) eu nao vou ter escolha a nao recomecar o projeto. Nesse sentido acho interessante ter tecnologias de mais alto nivel, como webwork e de mais baixo nivel, como o struts. Ha espaco para ambos.
Alem do mais, se eh para criticar coisas, jogar m**** no ventilador, falemos dos servlets. Para que menos orientado a objeto que o proprio servlet, um amontoado de funcao tambem. E o jsp entao, ficar misturando codigo com html, muito sem nocao.
Felizmente, ou infelizmente , heheheeh, foi criado um elefante branco chamado JSF. Esse finalmente sera uma tecnologia MVC que dara liberdade de escolha para o fornecedor (nao estou falando que o JSF eh bom, mas se voce quiser trocar seu myfaces para o jsf da sun, ou da ibm voce podera.)
Soh para finalizar, citando o livro o Java™ Performance and Scalability Volume 1: Server-Side Programming Techniques de Dov Bulka (Addison Wesley) que eu li, ele realiza testes em varios aspectos da linguagem java, fazendo microbenchmarks em streams, strings, comparar LinkedList e ArrayList, bem, no quisito criacao de objetos comparado com pool, o uso de pool eh 2 vezes mais rapido que a criacao de objetos novos. Bem, o Struts nem criar o objeto do Action precisa.
Nao quero dizer , em nenhum momento, que a criacao constante de objetos do webwork vai inviabilizar um projeto. Hoje em dia, com o poder computacional isso eh minimo. Soh estou expondo dois pontos chaves: nem todo mundo pode gostar da constante criacao de objetos do webwork, e para isso existe alternativa, o struts e outro ponto eh que o modelo do struts, de nao poder usar atributos, nem vem dele, ja vem do proprio modelo de servlet, e por que ninguem fala mal do modelo de servlet e propoe uma alternativa.
[quote=“tanque”]…
falemos dos servlets. Para que menos orientado a objeto que o proprio servlet, um amontoado de funcao tambem. E o jsp entao, ficar misturando codigo com html, muito sem nocao.
[/quote]
tem toda a razao!
[quote=“tanque”]…
Soh para finalizar, citando o livro o Java™ Performance and Scalability Volume 1: Server-Side Programming Techniques de Dov Bulka (Addison Wesley) que eu li, ele realiza testes em varios aspectos da linguagem java, fazendo microbenchmarks em streams, strings, comparar LinkedList e ArrayList, bem, no quisito criacao de objetos comparado com pool, o uso de pool eh 2 vezes mais rapido que a criacao de objetos novos. Bem, o Struts nem criar o objeto do Action precisa.
[/quote]
Esse livro eh de java 1.2! Eh incomparavel a runtime do java 1.4 com a do 1.2, em especial em relacao a essas coisas de criacao de objetos pequenos, etc. Hoje em dia nao compensa usar pool de jeito nenhum para objetos simples.
[quote=“Paulo Silveira”][quote=“tanque”]…
falemos dos servlets. Para que menos orientado a objeto que o proprio servlet, um amontoado de funcao tambem. E o jsp entao, ficar misturando codigo com html, muito sem nocao.
[/quote]
tem toda a razao!
[/quote]
Temos um problema aqui.
HTTP não é orienteado à objetos, existe uma fronteira entre paradigmas. É como falar que Hibernate é ruim porque lida com o paradigma relacional.
Um ‘adaptador’ como servlets encapsula a requisição para você, ora, quando você usa um servlet, você está trabalhando OO! Eu não conheço nenhum browser RMI/IIOP que minha mão conseiga usar como o browser HTMP sobre HTTP dela. Pelo menos, não por enquanto.
Não vejo motivos para tanta reclamação mesmo, o Servlet te entrega o Request como um objeto. Response, session, etc. também. Em HTTP, são mensagens de texto!
Se for pra jogar pedra na API, é melhor arrumar outro motivo
[]s
Nao quis chegar a tanto, soh quis exemplificar um caso que a abordagem nao eh tao orientada a objeto como poderia, mas tudo bem. Vamos as argumentacoes. O fato do HTTP nao ser orientado a objeto nao quer dizer que o tratamento dele nao precise ser orientado a objeto. Citemos alguns exemplos, a API do windows eh orientada a eventos, e existem varios wrappers para ela orientado a objeto, como por exemplo a MFC, OWL. Ate a VCL do delphi tem esses conceitos. A Xlib do unix eh a mesma coisa, mesmo assim existem modelos orientados a objetos, como o QT por exemplo.
Orientacao a objetos tambem eh realmente isso, esconder complexidade do software em involucros tipo caixa preta, entao essas bibliotecas escondem o modelo do xlib e do WIN32 em uma casca orientado a objeto.
A minha critica em relacao ao Servlets, que vem a ser a mesma critica que defensores do WebWork fazem relacao ao struts eh o fato de nao grudarem os Request, Response, etc, em atributos da Classe. Houve motivos para fazer isso, e passar esses elementos como parametros. O Fato que o struts usa a mesma abordagem e eh criticado. Bem, entao antes de tudo critiquem servlet, e nao soh o struts. Nao eh a primeira vez que houve erros de Design da linguagem / APIs do java e nao sera a ultima. Mas tudo bem, vamos levando, vamos consertando onde da, criando framewors que resolvem nossos problemas do dia a dia como por exemplo o struts e o webwork
O Hibernate nao se enquadra no mesmo ponto, porque apesar de lidar com um paradigma nao orientado a objeto , prove uma bela prova que se pode contruir uma boa camada de mapeamento orientada a objeto. Eh a mesma coisa das bibliotecas graficas que citei anteriormente. Prove uma boa abordagem orientada a objeto para algo que nao o eh.
Concordo, e é exatamente isso que a AP de Servlets faz.
Segundo o RFC 2068, o request, por exemplo, inclui diversas informações em texto, como este exemplo aleatório:
GET /Stuff/Funny/silly.html HTTP/1.0
User-agent: NCSA Mosaic for the X Window System/2.5
Accept: text/plain
Accept: text/html
Accept: application/postscript
Accept: image/gifOk, são propriedade de um pedido de conexão. Ate’onde eu aprendi, um objeto reúne dados [propriedades] e operações, logo estes deveriam estar contidos em um objeto ‘request’ utilizado. Você rpecisa fazer o parse destes dados de texto para objetos? Não, a especificação diz que você não precisa se preocupar com isso.
Note que encapsulamento não é um conceito exclusivo de programação OO, programação estruturada/procedural também utiliza este conceito.
Bem, afinal, qual o problema com os servlets? Onde você não programa orientado à objetos em um servlet? A encapsulação do HTTP em objetos é falha onde? Ok, nada é perfeito [e não estou ganhando nenhuma grana da Sun pra defender sua especificação], mas gostaria de algum argumento.
Hei, coisas diferentes aqui. Se você trabalhar com Struts, WebWork [creio], etc., vai estar colocando uma camada de abstração em cima dos servlets. Se os servlets [que são de baixo nível] encapsulassem o HTTP, me diga como você poderia ter acesso a um parâmetro passado por GET ou POST. ‘Ah, poderíamos ter tudo encapsulado em um modelo que livrasse o programador de sequer saber que aquilo é HTTP…’ e a curva de aprendizado seria enorme para alguém entender este adaptador. Seria criado um novo protocolo em cima do HTTP…
Servlets são baixo nível nesta especificação, não é a toa que tanta coisa é construída com base em servlets, de JSP à WebServices. Como são tão baixo nível, é preciso que reflitam o HTTP como ele é, é claro que de uma maneira OO, mas não podem esconder muitos detalhes. Se eu preciso saber que meu usuário me mandou um parâmetro num form HTML, isso não pode/deve ser muito diferente de qualquer outro programa que use HTTP!
O adaptador é provido pelo framework MVC ou o quer que você use em cima do Servlet. O ponto é que o Struts não abstrai tudo do programador, como deveria. Note também que não tenho nada contra Struts, mas a idéia de que ele parou de evoluir tem muito sentido para mim.
[quote=“tanque”]
O Hibernate nao se enquadra no mesmo ponto, porque apesar de lidar com um paradigma nao orientado a objeto , prove uma bela prova que se pode contruir uma boa camada de mapeamento orientada a objeto. Eh a mesma coisa das bibliotecas graficas que citei anteriormente. Prove uma boa abordagem orientada a objeto para algo que nao o eh.[/quote]
Exatamente como os Servlets. Encapsula algo que não é OO em adaptadores.
Por que usar Hibernate? JDBC não é OO?
Pois bem, com Mapemaentos O-R em geral, você colcoa algo acima da JDBC, nada mais de se preocupar com connections, statements… Assim como em uma camada de abstração sobre os servlets você não deveria se preocupar com request/response, isso é papel do seu framework que encapsula a APId e servlets, logo os processos HTTP.
Servlets/HTTP estão para o MVC como a JDBC está para um mapeamento O-R. Podeia ser melhor desenhada? Tudo pode ser malhor desenhado! Mas não é ruim, pelo cotnrário, serve à que se propõe, e muito bem.
[]s
Parece que voce mesmo responde sua pergunta:
em
Se eu derivar um HttpServlet, eu nao posso criar propriedades, somente operacao. Segundo o que voce mesmo definiu, eu tenho meio objeto, ja que nao posso ter propriedades, soh operacoes.