Pessoal, se vocês fossem começar a desenvolver um sistema que de curto/médio prazo fosse crescer muito.
Quais frameworks utilizariam ??
Claro essa pergunta não está sendo levada em conta modelagem, negócio, entre outros, pode ser refletida a partir de outros pontos de vista;
É umas suposição de algo que sabe-se que irá ser grande, e o ideal é estar preparado para ser de fácil manutenção(entenda por modificações significativas);
Depende de quem vai implementar… a melhor tecnologia é aquela que você conhece.
Se você se garante nas tecnologias acima… vai na fé. O resto é bla bla bla.
Não caia na conversa que uma tecnologia é melhor que outra se você não tem tempo ou condições de correr riscos.
Geralmente quem opta por tecnologia novas em projetos de prazos apertados “acabam desenvolvendo hábitos pouco ortodoxos, como andar pelo escritório batendo o próprio saco nas quinas dos cubículos”.
Certo, mas tem um porém…
também conheço Struts 2 mas acredito ser um framework muito imaturo comparado ao 1.
Isso poderia ser um fator risco, pois bug de framework só parece quando não se tem tempo…rs
ou estou errado ??
Não existe o conjunto de frameworks perfeitos para todas as situações.
Na minha opinião por exemplo, se você vai ter uma interface mais rica, quer aproveitar melhor os componentes, voc6e pode partir para JSF, enquanto se for mais o estilo tradicional, action-based, você pode ir para Struts 2.
Agora Struts 1? isso é passado cara, ele te dá um alto acoplamento, um XML monstro, além de outros problemas. Para projetos novos, fuja dele!!!
Como eu disse acima, não existe um conjunto ideal para todos os casos, mas eu acho que vale muito a pena tirar um tempo e dar um olhada no JBoss Seam
Interessante, então no meu caso vale mais a pena usar o Struts 2 até por já possuir conhecimento;
Também vou olhar o Jboss Seam … tem dicas dele ai rs ??
Quem sou eu para dizer para você escolher por uma tecnologia ou outra… Escolher uma tecnologia nova é assumir um baita risco.
Mas eu acho ( e não coloque a culpa em mim se alguma coisa der errado) que o Struts 2 já é uma tecnologia madura.
Você deve escolher os frameworks que te permitam que seu código seja escrito de maneira mais simples possível. É dessa simplicidade que vem a facilidade de manutenção.
Minha opinião: JPA facilita, e muito, a integração com a base de dados. EJB, apenas se você precisar dos recursos que ele oferece, se não precisá-los, é dispensável. Struts 1.x é problemático, porque não facilita, só complica. De framework web, preferiria Seam, Wicket ou Ruby on Rails.
[quote]rodrigousp wrote
…( e não coloque a culpa em mim se alguma coisa der errado) …
[/quote]
é claro que não irei culpar ninguém, estou justamente querendo opiniões para tomar a melhor decisão…
experiência sempre conta …rs por isso postei minha idéia aqui …
Pegando o bonde andando… mas clusterizar não é sinônimo de melhoria de performance.
Se sua intencao é balanceamento de carga, ai mesmo só com camada web(sem ejbs) vc consegue utilizando um apache na frente e varios tomcats, jettys ou qualquer webcontainer atrás.
Procure algum fw de negocio que vc tenha velocidade e nao precise de “deploy” com isso com certeza vc vai ganhar tempo.
Clustering quase sempre diminui a performance individual de cada servidor. Porém torna a solução mais eficiente.
Porém para 99% dos sistemas que eu já vi, escalar verticalmente é muito mais barato e fácil. Em vez de se matar
em tornar o sistema clusterizavel, compra logo um servidor de 16 cores com 64 Gigas de ram e pronto. Vai custar uma
fração da outra opção.
Tem um interessante artigo no serverside que fala sobre sistemas escaláveis.
Uma das coisas interessantes está nesses parágrafos:
[quote]
Use collocated deployment instead of distributed one
Java EE technology, especially EJB, was born for distributed computing. Decoupled business functionality and reused remote components make multi-tier applications popular. But for scalability, reducing the distributed layers maybe a good choice.
The result was that the collocated structure scaled much better than the distributed one! Imagine in one method in your application you may be invoking a couple of EJBs. If you load balance on every one of those EJBs, you’re going to end up with instances of your application spread out across the multiple server instances. As a result, you’re going to have a lot of server-to-server cross talk that’s unnecessary. And more, if your method is under a transaction, your transaction boundary will include many server instances which will impact performance heavily.[/quote]
Quer dizer… às vezes soluções mais simples, são mais escaláveis. (ou você não precisa se matar para colocar um sistema em grid para conseguir escalabilidade). E, é sempre bom lembrar de exemplos como a Wikipedia que não utilizam nada como EJB e escalam super bem.
Cara eu estive com a mesma dúvida há um tempinho atrás e eis as minhas escolhas :
Struts 2 (qdo vi que não precisei fazer quase nada de XML e resolvi muita coisa do struts 1 com annotations não tive dúvidas)
Hibernate (um dao genérico me poupou uma cassetada de trabalho, pouquíssimo XML e muita produtividade. Ainda tem algumas coisas que preciso ajustar mas 90% dos problemas estão resolvidos)
Tomcat (não vou usar ejb. por isso, tomcat, resin, jetty qq um deles resolveria na boa)
Oracle
E quais opções que não escolhi ainda ou que não irei utilizar e o porquê delas :
Tiles (eu quero usar, deve ser bom, mas por enquanto os includes do struts estão resolvendo)
JSF (também deve ser muito bom mas como não tenho domínio… prefiri o tradicional que eu me garanto rs)
Spring (praticamente todos os tutoriais que eu vejo fazem referência a ele, é algo que tenho que olhar não é possível todos estarem errados rs)
A minha principal preocupação foi EU vou saber mecher com o treco ou não ?
Não adiantava nada pra mim saber que pra 100 pessoas tinha sido ótimo e fantástico mas eu não saber usar o framework e acabar atrasando/travando tudo.
E por fim, há a expectativa de novas contratações em razão do crescimento do projeto.
Por isso, optei pelas opções mais “comuns” e conhecidas do mercado. Assim, a adaptação de um novo membro na equipe não seria tão complicada.
Como a solução é a médio prazo, acho que vale o investimento em algum outro framework que não o struts até mesmo porque voce possui tempo para capacitação da equipe. Investir em Struts 1 ou 2 e depois ver, no meio do projeto, que suas demandas não são atendidas é complicado…
