Arquivo Discussoes de Programacao e Tecnologia 
E aê pessoal,
Tudo blz!?
Então, queria a opinião de vcs com relação a migração da camada de apresentação de um sistema Struts 1.x para:
Principalmente com relação ao que está sendo realmente utilizado no mercado corporativo.
Valeu por qualquer contribuição!
Acho que você tem que pensar com qual framework você se sente mais a vontade de trabalhar, porque este será o framework que você tera
um melhor aproveitamento.
Na minha opinião eu ia de JSF 2 + Primefaces.
Mais pra quem gosta de framework action based acredito que o mais produtivo seja o vRaptor.
Acredito que seria melhor migrar para o struts 2,pois vai ser o que se terá menor quantidade de problemas.
Mudar para jsf 2 é mudar até o paradigma, de action based para component based.
Acredito que seria melhor migrar para o struts 2,pois vai ser o que se terá menor quantidade de problemas.Mudar para jsf 2 é mudar até o paradigma, de action based para component based.
Cara na boa sair de Struts 1.x e ir pra Struts 2 acho meio que tiro no pé… em tempos
que existe frameworks action based que são superiores tais como vRaptor, Mentawai, Grails e Play.
Migrar de um framework pra outro e sempre um parto… acho que o X da questão e fazer um escolha que possa
evoluir o projeto.
O problema é. Ele tem tempo de fazer a migração desse tipo, porque é praticamente refazer o sistema.
Vai ter tempo para estudar o novo sistema ?
O cliente vai querer pagar o tempo a mais ?
Aqui na empresa temos uma situação muito semelhante: precisamos migrar os sistemas de JSF 1.1 para alguma tecnologia mais moderna.
A equipe responsável por isso já fez protótipos com Wicket, Vaadin e JSF 2 com Prime Faces. Ninguém ousou tentar o GWT ainda, mas é uma opção interessante. Para desenvolvimento ágil, há o “play! framework”, mas só recomendo se a equipe de desenvolvimento for de alto nível.
A princípio, JSF 2 parece ser o caminho natural, mas aqui houve um grande impasse. Nos testes dessa equipe, foi identificado que há diferenças significativas entre o JSF 1 e 2 a ponto de várias coisas não funcionarem como esperado. Temos tantas telas em JSF 1 e o esforço de homologar tudo novamente está gerando um certo impedimento para a migração. É um ponto que deve ser levado em consideração, pois dependendo de como está a implementação atual, a migração para JSF 2 não será tão suave.
Ninguém conseguiu também criar um sistema híbrido, com uma parte em JSF 1 e outra com JSF 2, por causa de incompatibilidade entre jars. Dessa forma a migração poderia acontecer gradualmente. Com outras tecnologias isso provavelmente é possível, já que não haverá sobreposição de classes. Uma possível solução para migração gradual de JSF 1 para 2 seria dividir o sistema em 2 e usar Single Sign On para que o usuário não perceba que está usando duas aplicações diferentes.
Eu, particularmente, não gosto de JSF por vários motivos.
Recentemente desenvolvi um sistema usando FreeMarker (linguagem para templates) e Bootstrap Twitter (biblioteca html/css/javascript que provê componentes HTML) desvinculando totalmente as tecnologias utilizadas nas camadas de Visão e Apresentação. Gostei dessa solução embora perca algumas das vantagens de se usar um framework mais popular.
O problema é. Ele tem tempo de fazer a migração desse tipo, porque é praticamente refazer o sistema.
Vai ter tempo para estudar o novo sistema ?
O cliente vai querer pagar o tempo a mais ?
É aonde e que ta a facilidade de migrar um projeto de struts 1.x pra struts 2?
Meu caro muita coisa mudou da versão 1.x pra versão.
Migrar de Struts 1 para 2 é mudar de Framework.
Struts 2 não é igual a Struts 1, tem muitas diferenças, pois, ele englobou o framework WebWork, o que o tornou mais robusto e poderoso, incluindo coisas que o Struts 1, nascido em 2000, nem imaginava, como os interceptors e sepultou os FormBeans que, convenhamos, só serviam para encher o saco.
O Struts 2, ao menos no quesito organização (e na minha opinião) é mais interessante que o JSF 2, além do que, é responsável por injetar os objetos que são utilizados nas jsps, o que, o JSF 2 não faz (tente referenciar um objeto do ManagedBean sem instanciá-lo e submeta a página, você terá um belo NPE).
Mentawai, vRaptor e Play! são opções interessantes, que merecem uma olhada com carinho.
Acredito que pra isso pode se utilizar CDI do JEE 6 ou qualquer outro container DI(pico, guice, spring).
Eu não disse que era fácil, só que ainda é action based e o modelo de action, forward e tal continuou igual, ainda mais se ele usava struts 1 com parameter.
Agora trocar para jsf 2 é melhor ao invés de migrar fazer tudo do zero novamente, porque é uma troca total de paradigma.
Ainda não estamos considerando o fator tempo e grana, o qual para o cliente se deixar importa mais que atualizar tecnologia.
Acredito que pra isso pode se utilizar CDI do JEE 6 ou qualquer outro container DI(pico, guice, spring).
Claro, e você transforma uma coisinha simples em uma bola de neve gigantesca.
A questão é que o Struts 2 simplifica isso. Claro que você pode usar mais frameworks, tirar a aplicação do Tomcat e colocar no JBoss, mas, só para ter objetos injetados?
Eu não disse que era fácil, só que ainda é action based e o modelo de action, forward e tal continuou igual, ainda mais se ele usava struts 1 com parameter.
Agora trocar para jsf 2 é melhor ao invés de migrar fazer tudo do zero novamente, porque é uma troca total de paradigma.Ainda não estamos considerando o fator tempo e grana, o qual para o cliente se deixar importa mais que atualizar tecnologia.
Que eu saiba o o container DI do Spring não necessita de AS pra rodar… consequentemente pode
ser executado num Tomcat, Jetty e por ai vai…
Que eu saiba o o container DI do Spring não necessita de AS pra rodar… consequentemente pode´
ser executado num Tomcat, Jetty e por ai vai…
E o CDI que você citou? E o JEE 6?[…]
Fato… mais foi por isso que eu adicionei outros container de DI tais como Pico, Guice e Spring DI que não necessita de um AS pra ser executado.
Além do que, como eu disse, por que eu vou precisar inserir mais uma porrada de jars na aplicação, se posso resolver apenas com Struts2?[…]
Entendo e respeito sua colocação, mais pelo que você ta falando… podemos considerar o Struts 2 como um canivete suiço? to trabalhando com Struts 2 e não
preciso mais de nada… fod#!$^&-se o mundo tenho tudo… Tudo bem que o Struts 2 tem la um container de DI que far o trabalho legal, mais nada impede se
usar outro até por que duvido que o DI do Struts tenha o mesmo poder de fogo que o Spring ou CDI do JEE 6…
E o CDI que você citou? E o JEE 6?[…]Fato… mais foi por isso que eu adicionei outros container de DI tais como Pico, Guice e Spring DI que não necessita de um AS pra ser executado.
Em nenhum momento disse isso.
Struts 2 é manco como todos os demais frameworks que não são full-stack.
O que eu disse é que Struts 2 é melhor, sob o ponto de vista de não precisar instanciar o objeto que irá representar um campo na view.
Não sei por que você ficou estressadinho.
Já fiz muita coisa com Struts 2, hibernate, Spring, JFreeChart e iReport. E também muita com JSF2, Spring e EclipseLink…
Certo pessoal,
Obrigada pelas respostas!
Então poderia até presumir que o tempo de migração para Struts2 será menor do que para JSF/JSF2, se a equipe já tivesse trabalhado com este framework, porém a equipe já trabalhou (e trabalha) com JSF 1.2.x.
Claro que o tempo conta muito para o cliente, e este é um fator que deve ser levado em conta, mas o não domínio da equipe na tecnologia (Struts2), leva a crer que a migração para JSF deverá ser a saída.
Sem dúvida.
Agora não seria melhor fazer um outro sistema nesse caso ?
A mudança na view vai ser muito impactante, desde a forma como os componentes são criados, passando pela própria extensão, que se for jsf 2 será utilizado o facelets, isso se não estiver usando o tiles para o struts.
Parte de validação deve estar sendo feita com aqueles xml’s gigantes.
Tomara que o sistema pelo menos tenha sido bem estruturado e não tenha regra de negócio na action, pois senão é mais trabalho ainda.
Uma pergunta. Porque vocês tem que migrar o sistema ?
Sem dúvida praticamente será criado um novo sistema.
A migração se deve ao fato de o cliente exigir o sistema em uma dessas tecnologias (Struts2 ou JSF), e hoje ele é feito em Struts 1.x…
Sem dúvida.
Agora não seria melhor fazer um outro sistema nesse caso ?
A mudança na view vai ser muito impactante, desde a forma como os componentes são criados, passando pela própria extensão, que se for jsf 2 será utilizado o facelets, isso se não estiver usando o tiles para o struts.
Parte de validação deve estar sendo feita com aqueles xml’s gigantes.
Tomara que o sistema pelo menos tenha sido bem estruturado e não tenha regra de negócio na action, pois senão é mais trabalho ainda.Uma pergunta. Porque vocês tem que migrar o sistema ?
E qual o ganho ele vai ter com isso em termos de ROI?
Vai de Bootstrap + Struts 2 (ou outro que achar melhor baseado em action). Experiência própria recente em .NET (com framework baseado em action), melhor relação controle x produtividade pensando em manutenção e não só no desenvolvimento inicial.