Seam x Spring

pcassiano:

Gostaria de obter, em linhas gerais, um comparativo técnico entre os frameworks Seam e Spring.

Se você tem experiência em ambos, pode me dizer, por exemplo, quais são as 10 [color=blue]coisas boas[/color] e as 10 [color=red]coisas ruins[/color] de cada um?

Veja que estou pedindo um comparativo técnico e não me interessa gerar flames. Vamos manter o nível da discussão “lá em cima”, OK?

Nossa… dez coisas é difícil de levantar duma vez só.

Primeiramente, quero te lembrar uma coisa: Seam e Spring têm propósitos diferentes, então, não dá pra falar de um “comparativo” , é o mesmo que comparar maçã com banana.

Nunca usei os dois em conjunto, mas, separados, eles são muito bons naquilo que se propõem. Vamos lá:

Coisas boas Seam:

1. Permite integração direta de tags JSF com EJBs (carro-chefe do framework);
2. Utiliza JBoss EL (que dá a capacidade , dentre outras coisas, de invocar métodos, passando parâmetros e tudo mais, na própria EL);
3. Implementa contexto de conversação, ou seja, determinado contexto é válido “para algumas páginas” (é um modelo intermediário entre o contexto de requisição e o de sessão);
4. Facilita tarefas de persistência, como por exemplo: se eu persisto a entidade X, então o Seam irá controlar o contexto de persistência - transações e tudo mais - e ainda irá colocar uma mensagem no contexto JSF dizendo que a entidade foi persistida;
5. É facilmente integrável com jBPM (aliás, para saber mais sobre o jBPM, consulte o artigo “Workflows com jBPM”, na Java Magazine 71 - eu sou o autor!! =P );
6. Possui uma biblioteca de tags que habilita, entre outras coisas, a integração com Hibernate Validator;
7. É amplamente configurável através de annotations.

Coisas ruins Seam:

1. Se você precisar usar algum componente Seam de fora do contexto, prepare-se para ter trabalho - isso é um tanto chato de fazer (porém, “chato” não quer dizer “impossível”);
2. O modelo de conversação possui diversas limitações;
3. Se você precisar remover , ou simplesmente não quiser colocar, algumas mensagens que ele coloca automaticamente no contexto, está ferrado - terá que fazer alguma gambiarra com reflections para tirá-las de lá;
4. É chato (de novo, “chato” não é “impossível”) de configurar em outro application server que não o JBoss;
5. Ele “mexe” no modelo default de classes do jBPM - o que dá algumas dores de cabeça, às vezes.

Coisas boas Spring:

1. É o Spring!! =P
2. Ele te ajuda com transações;
3. Ele te ajuda com injeção de dependência;
4. Ele te ajuda com AOP;
5. Ele te ajuda com EJBs;
6. Ele te ajuda com MVC;
7. Ele te ajuda com segurança;
8. Ele te ajuda com praticamente todos os frameworks que já estão bem estabelecidos no mercado.

Coisas ruins Spring:

1. Ele te faz se acostumar com ele e não querer mais largar =P

(Sério, não sei o que falar de ruim do Spring)

Espero ter ajudado. Essas são algumas características dos dois frameworks que consigo lembrar, mas caso lembre de mais alguma coisa, complemento a lista.

[]´s

Muitíssimo obrigado asaudate pelas suas colocações! Estou aprendendo muito mesmo! Se lembrar de mais alguma coisa, por favor, compartilhe!

Quem tem algo mais a acrescentar?

sente a falta de conhecimento…

:arrow: O Seam me parece “perfeitamente alinhado” com os demais “produtos” da JBoss, estou certo? E o “casamento” Spring + JBoss, é igualmente bom?

:arrow: O Spring me parece ser muito “maior” que o Seam, mais “abrangente” e “perfeito” para sistemas maiores, tipo Portais. Estou certo?

:arrow: Caso eu queira que minhas [color=red]Views[/color] não utilizem JSF, mas sim XHTML e CSS (webstandards), ambos têm este suporte?

:roll:

sente a falta de conhecimento…

:arrow: O Seam me parece “perfeitamente alinhado” com os demais “produtos” da JBoss, estou certo? E o “casamento” Spring + JBoss, é igualmente bom?

O Spring funciona em todo (pelo menos, eu nunca ví não funcionar em algum) servidor (Tomcat, JBoss, Weblogic, Websphere…)

Ambos têm propósitos diferentes, e não são mutuamente exclusivos (não estou certo se a integração entre eles é possível, mas é fato que atuam em nichos diferentes). Sei que o Spring aguenta praticamente “qualquer parada”. Quanto ao Seam, nunca testei em aplicações muito grandes.

Spring, sim. Seam (desculpe o trocadilho!) , não.

Mias uma vez, muitíssimo obrigado asaudate pelas suas colocações! Continuo aprendendo muito mesmo!

Necessário não é, porém se mais alguém quiser acrescentar algo ao que já foi dito, será bem-vindo!

[color=olive](gostaria de ler sobre as “limitações” e “problemas” do Spring e, claro, sugestões para resolver tudo, ou pelo menos, “contornar” tudo…)[/color]

Tbm curto bastante o spring…

O Spring…

:arrow: … permite que se use na View [color=violet]jQuery[/color] “sem maiores complicações”?

:arrow: … permite que se capture coisas com JSON e persista este tipo de objeto em banco “sem maiores complicações”?

:arrow: … se integra bem com o Hibernate, “sem maiores complicações”?

:arrow: color=brown o Hibernate permite “versionar” as alterações em BD, a exemplo do ActiveRecord (Rails)?[/color]

Spring…

… permite que se use na View jQuery “sem maiores complicações”?

… permite que se capture coisas com JSON e persista este tipo de objeto em banco “sem maiores complicações”?

… se integra bem com o Hibernate, “sem maiores complicações”?

(off-topic) o Hibernate permite “versionar” as alterações em BD, a exemplo do ActiveRecord (Rails)?

O Spring pode ser usado com jQuery sim, sem problemas. Lembre-se de que ele é um framework para backend, ou seja, não é afetado pelo front-end.

Quanto ao JSON… não sei, nunca tentei.

Quanto ao Hibernate… eles formam um p&%$ dupla

Ah… vale lembrar que a documentação do Spring é maior e melhor que qualquer livro sobre ele. Vale a pena dar uma olhada

-> O Hibernate permite versionar as alterações através do plugin Envers, do próprio Hibernate. Não é bem como o ActiveRecord, mas versiona do mesmo jeito.

[]´s

asaudate - ou outro colega - já testou o Spring 3 com JEE 6?

Como estou começando agora com Spring, gostaria de começar com o que existe de mais atual, porém sei que nem sempre o que é “atual” está “maduro”, e não gostaria de ter de “voltar atrás” em busca de alguma “estabilidade”… :roll: