10 enganos comuns sobre o framework Spring

Uma ótima listinha com erros e enganos comuns a ditos ou "pensados" por quem ainda não conhece o framework Spring saiu no OnJava:

1. O Spring não é leve. Ele tenta fazer de tudo e está se tornando "gordo".
2. O Spring é um "tiro no pé" para pequenos projetos.
3. O Spring não é escalável para aplicações grandes.
4. O Spring força você a utilizar programação orientada a aspectos (que é uma coisa experimental).
5. O Spring substitui o Java EE.
6. Spring e EJB são mutuamente exclusivos.
7. O Spring não pode se aproveitar das novidades do Java 5 como o EJB.
8. Para grandes aplicações, a configuração do Spring pode se tornar um pesadelo para manutenção.
9. Spring faz tudo por reflexão, por isso ele é lento.
10. O Spring MVC é extremamente complexo, diferentemente do resto do Spring.

Lista completa (com comentários): OnJava - Ten Common Misconceptions About Spring...

Só alguns comentários com a minha opinião (não quer dizer que seja verdade, é só a minha opinião

)

Maurício Linhares wrote:Uma ótima listinha com erros e enganos comuns a ditos ou "pensados" por quem ainda não conhece o framework Spring saiu no OnJava:

1. O Spring não é leve. Ele tenta fazer de tudo e está se tornando "gordo".

O core do spring é bem leve, e tu só precisa usar os componentes que tu quiser ...
mas realmente ele esta se tornando "gordo"

Maurício Linhares wrote:
2. O Spring é um "tiro no pé" para pequenos projetos.

não acho que seja, principalmente quando ja tem um exemplo parecido pronto ...
Utilizei o spring-annotation para fazer um sisteminha de controle de inscrições para eventos do RSJUG, menos de 10h de trabalho, ou seja um sisteminha beem pequeno ...
7 ou 8 cadastros, ...
e poupei muito tempo usando o spring-annotation, e por consequencia o spring.

Maurício Linhares wrote:
3. O Spring não é escalável para aplicações grandes.

verdade ...
se tu precisar de objetos distribuidos, o spring não vai te dar isto ...

Maurício Linhares wrote:
4. O Spring força você a utilizar programação orientada a aspectos (que é uma coisa experimental).

não acho que AOP seja um problema ...
mas a maior parte dos usuários do spring não faz ideia que esta usando AOP por traz ...
mas se for pensar assim ...
EJB3 te força a usar AOP também ...

Maurício Linhares wrote:
5. O Spring substitui o Java EE.

nops ...
Java EE faz coisas que spring não faz ...

Maurício Linhares wrote:
6. Spring e EJB são mutuamente exclusivos.

também não é verdade ...
acessar EJBs de dentro do spring é até beem fácil

antes do EJB3 era até mais fácil do que via código java ...

Maurício Linhares wrote:
7. O Spring não pode se aproveitar das novidades do Java 5 como o EJB.

não é verdade ...
o spring-annotation esta ai pra provar o contrário ...
e na proxima versão ja vai conter anotações compativeis com Java EE 5

Maurício Linhares wrote:
8. Para grandes aplicações, a configuração do Spring pode se tornar um pesadelo para manutenção.

isto é verdade ...
e também um dos motivos que iniciei o desenvolvimento do spring-annotation

Maurício Linhares wrote:
9. Spring faz tudo por reflexão, por isso ele é lento.

não acho ele lento, pelo menos não chegou a ser visivel nas situações em que usei ele ...
mas também não fiz nenhum benchmark ...

Maurício Linhares wrote:
10. O Spring MVC é extremamente complexo, diferentemente do resto do Spring.

yeap, verdade ...
o Spring MVC é extremamente complexo, tem uma tonelada de recursos ...
com certeza mesmo no caso mais simples, ele é mais complicado que o necessário :S

a não ser se for utilizaro o spring-annotation

mas com certeza o spring não é a solução para todos os problemas da humanidade

Assim, só pra constar mesmo, isso é uma lista de coisas erradas que as pessoas que não conhecem costumam pensar sobre o Spring. Não uma lista dos problemas reais do Spring.

tem coisas listadas ali que realmente são problemas, e outras que estou tentando resolver com o spring annotation

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

urubatan wrote:
yeap, verdade ...
o Spring MVC é extremamente complexo, tem uma tonelada de recursos ...
com certeza mesmo no caso mais simples, ele é mais complicado que o necessário :S

Olá,

eu também achava um pouco complexo, mas acho que mudei de idéia. Vejam isso: http://static.springframework.org/spring/docs/2.0.x/reference/mvc.html#mvc-coc

Fiz a combinação das convenções + MultiActionController, e achei louco!

yeap ta ficando beem legal mesmo

mas acho que por mais fácil que fique, sempre vai ser dificil demais

o ideal era não precisarmos nos preocupar com isto

urubatan wrote:yeap ta ficando beem legal mesmo
mas acho que por mais fácil que fique, sempre vai ser dificil demais
o ideal era não precisarmos nos preocupar com isto

Eu nao sei pq mas nunca gostei do Spring MVC, sempre preferi o WebWork.
Mas vou dar uma olhada nesse link melhor parece que ta mudando o esquema.

Fala Urubatan...

Eu vou comentar um pouco sobre a sua opinião... ok?

urubatan wrote:

Maurício Linhares wrote:
1. O Spring não é leve. Ele tenta fazer de tudo e está se tornando "gordo".

O core do spring é bem leve, e tu só precisa usar os componentes que tu quiser ...
mas realmente ele esta se tornando "gordo"

Como assim se tornando "gordo"? O que é um framework "leve" pra você?

Um framework "leve" (lightweight) é um framework não intrusivo, isto é, não requer que classes da aplicação (domain model) fiquem "penduradas" nas interfaces/classes do framework (POJO). É exatamente o que o EJB não é, pelo menos até a versão 3! Assim, um framework não deixa de ser "leve" pelo seu tamanho. Enquanto Spring seguir essa filosofia, ele será considerado "leve" sim.

urubatan wrote:

Maurício Linhares wrote:
3. O Spring não é escalável para aplicações grandes.

verdade ...
se tu precisar de objetos distribuidos, o spring não vai te dar isto ...

O fato de Spring não trabalhar com Objetos Distribuidos não tira a escalabilidade de uma aplicação. Sem contar que distribuição de objetos é um assunto muito questionável (o livro 'J2EE Development without EJB', do Rod Johnson fala melhor sobre isso).
Portanto, não vejo onde ele perde em escalabilidade.

Bom amigos, após o terceiro projetinho com o Spring, fica aqui algumas impressões:

- Realmente para aplicações de médio porte, você começa a sentir que a manutenibilidade da aplicação é bastante prejudicada pela configuração e se você não adotar algumas convenções, fica difícil pegar o erro.

-MVC do Spring funciona muito bem, mas carece de uma revisão e melhoria em partes comuns, como métodos bind, getErrors, que você tem no SimpleFormController, mas quando vai usar o MultiActionController não os têm e vice-versa - caso do bind para o SimpleFormController (Existe até um parecido - bindAndValidate).

O que sugeria é a padronização da camada de infra-estrutura.

- Validator, você pode usar de uma determinada forma com alguns controllers - SimpleForm por exemplo e não pode usar no MultiAction. Exige outro formato de implementação que não é documentado, apenas referenciado em Apis - JavaDocs ... isso é um saco.

IoC - Se não tomar bastante cuidado, vai ter uma porrada de interfaces para classes de business, daos, e cruzamento das mesmas em várias implementações, como numa classe de business, que vai fazer uso de diversas outras interfaces de business e se não tiver tudo bem amarrado no xml, pau ... isso pode ser perigoso.

Ponto positivo é o debug com log4j, depois de alguns erros, você acaba sacando onde está o problema e vai direto ao ponto.

JSTL - TagBind, tem sérios problemas, e falta uma estrutura MVC na camada view.

PS: Depois termino, preciso sair fora do escritório, estou sozinho e o tiozinho aqui quer fechar

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Kenobi wrote:
JSTL - TagBind, tem sérios problemas, e falta uma estrutura MVC na camada view.

Não seria isso aqui o que voce precisa? http://static.springframework.org/spring/docs/2.0.x/reference/mvc.html#mvc-formtaglib

Kenobi wrote:
- Realmente para aplicações de médio porte, você começa a sentir que a manutenibilidade da aplicação é bastante prejudicada pela configuração e se você não adotar algumas convenções, fica difícil pegar o erro.

Se voce está falando de XMLs, concordo em partes, principalmente se não quebra-los por módulos, camadas, etc etc, sendo que a melhor estratégia varia de projeto pra projeto. Mas se a manutenibilidade da sua aplicação está ficando complicada, talvez seja hora de revisar a sua estratégia.
Como voce esta dividindo seus modulos nos XMLs?
Ah... e quais erros que sao dificies de pegar?

Kenobi wrote:
-MVC do Spring funciona muito bem, mas carece de uma revisão e melhoria em partes comuns, como métodos bind, getErrors, que você tem no SimpleFormController, mas quando vai usar o MultiActionController não os têm e vice-versa - caso do bind para o SimpleFormController (Existe até um parecido - bindAndValidate).

Bom, SimpleFormController e MultiActionController são coisas bem distintas!
Mas, de qualquer maneira, talvez o que esteja procurando seja um 'MultiActionFormController' (http://opensource.atlassian.com/projects/spring/browse/SPR-1606).

Kenobi wrote:
IoC - Se não tomar bastante cuidado, vai ter uma porrada de interfaces para classes de business, daos, e cruzamento das mesmas em várias implementações, como numa classe de business, que vai fazer uso de diversas outras interfaces de business e se não tiver tudo bem amarrado no xml, pau ... isso pode ser perigoso.

Não entendi...
"como numa classe de business, que vai fazer uso de diversas outras interfaces de business"... como assim? O que é perigoso?

Kenobi wrote:
Ponto positivo é o debug com log4j, depois de alguns erros, você acaba sacando onde está o problema e vai direto ao ponto.

Isso é o que todo bom framework tem!

Kenobi wrote:
JSTL - TagBind, tem sérios problemas, e falta uma estrutura MVC na camada view.

O que é TagBind? E quais os sérios problemas?

Na versão 2.0 temos o form tag library.

Gerson wrote:Fala Urubatan...

Eu vou comentar um pouco sobre a sua opinião... ok?

OK, sem problemas

Gerson wrote:
Como assim se tornando "gordo"? O que é um framework "leve" pra você?

Um framework "leve" (lightweight) é um framework não intrusivo, isto é, não requer que classes da aplicação (domain model) fiquem "penduradas" nas interfaces/classes do framework (POJO). É exatamente o que o EJB não é, pelo menos até a versão 3! Assim, um framework não deixa de ser "leve" pelo seu tamanho. Enquanto Spring seguir essa filosofia, ele será considerado "leve" sim.

Por este ponto de vista, eu estava comparando o tamanho do framework só

Gerson wrote:
O fato de Spring não trabalhar com Objetos Distribuidos não tira a escalabilidade de uma aplicação. Sem contar que distribuição de objetos é um assunto muito questionável (o livro 'J2EE Development without EJB', do Rod Johnson fala melhor sobre isso).
Portanto, não vejo onde ele perde em escalabilidade.

Posso ter me expressado mal, o que eu disse foi "se voce precisar de objetos distribuidos"
até o momento vejo poucas ocasiões onde isto é realmente necessário

e até quando é, normalmente chamo um EJB de dentro do contexto do spring

Eu gosto muito do spring, faço sempre palestras sobre ele (inclusive vo fazer uma no proximo JustJava, e uma sobre Spring-Annotation no proximo tutorial do RSJUG.
Uso Spring em praticamente todos os projetos em que tenho trabalhado nos ultimos 2 anos

mas realmente acho que ele precisa melhorar em alguns pontos

e este é o meu foco com o projeto Spring-Annotation

GUJ Ranger Membro desde: 21/07/2005 08:51:27 Mensagens: 807 Offline

Hummm... se o Spring tem tantos defeitinhos que podem prejudicar o futuro do projeto, qual outro framework vcs acham que esta muito bem estruturado alem de ter facil manutenbilidade e coisas do tipo?? seria o JSF???

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

JSF != Spring

mas algo similar ao spring que tenho vontade de aprender seria o Hivemind, apesar do Spring ser mais abrangente.

Segue uma comparação que achei no google: http://howardlewisship.com/blog/2004/02/comparing-hivemind-to-spring.html

urubatan wrote:
mas realmente acho que ele precisa melhorar em alguns pontos
e este é o meu foco com o projeto Spring-Annotation

Bom, eu não conheço bem esse seu projeto Spring-Annotation, mas, a principio, o que não me agrada é o fato de parecer mais um Dependency Lookup (Service Locator) do que Dependency Injection, já que o componente está, ativamente, solicitando (mesmo que não seja via código diretamente) sua dependencia para o container (usando @Property do Spring-Annotation). Usando Dependency Injection, o componente que precisa das dependencias é passivo (nao é ele que "corre atrás" de suas dependencias), o que não ocorre com o Spring-Annotation. Prefiro que o componente não fique responsável por saber quem são suas dependencias... acho que @Property(ref="dependenciaBean") quebra a DI.

Notícias, artigos e o maior fórum brasileiro sobre Java