Só alguns comentários com a minha opinião (não quer dizer que seja verdade, é só a minha opinião )
[quote=Maurício Linhares]Uma ótima listinha com erros e enganos comuns a ditos ou “pensados” por quem ainda não conhece o framework Spring saiu no OnJava:
O Spring não é leve. Ele tenta fazer de tudo e está se tornando “gordo”.
[/quote]
O core do spring é bem leve, e tu só precisa usar os componentes que tu quiser …
mas realmente ele esta se tornando “gordo”
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.
verdade …
se tu precisar de objetos distribuidos, o spring não vai te dar isto …
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 …
nops …
Java EE faz coisas que spring não faz …
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 …
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
isto é verdade …
e também um dos motivos que iniciei o desenvolvimento do spring-annotation
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 …
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
@Bean
@UrlMapping("/index.do")
public class QualquerNome implements Controller{....}
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.
[quote=urubatan]
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[/quote]
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
[quote=urubatan]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
[/quote]
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.
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.
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
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?
Eu vou comentar um pouco sobre a sua opinião… ok?
[/quote]
OK, sem problemas
Por este ponto de vista, eu estava comparando o tamanho do framework só
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
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???
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.
Esse é o problema !! Eu conheço a hierarquia e ambos controllers são utilizados para tarefas parecidas, a diferença que no multiaction você pode ter concentrado num mesmo vários métodos e expor diretamente à aplicação, concentrando recursos num controller.
Sou fã de uma revisão como o proposto no link, realmente não acredito que tinha necesssidade de ser tão diferente, poderiam concentrar os serviços - infra na base e depois tudo bem mudar a hierarquia.
Esse é o problema !! Eu conheço a hierarquia e ambos controllers são utilizados para tarefas parecidas, a diferença que no multiaction você pode ter concentrado num mesmo vários métodos e expor diretamente à aplicação, concentrando recursos num controller.
Sou fã de uma revisão como o proposto no link, realmente não acredito que tinha necesssidade de ser tão diferente, poderiam concentrar os serviços - infra na base e depois tudo bem mudar a hierarquia.
:idea: [/quote]
Tinha sim!
Aí que tá, a diferença entre SimpleFormController e MultiActionController é muito mais que ''ter concentrado num mesmo vários métodos e expor diretamente à aplicação!
SimpleFormController foi criado para se trabalhar com formulário. Dê uma olhada no workflow em sua superclasse para entender a diferença: http://www.springframework.org/docs/api/org/springframework/web/servlet/mvc/AbstractFormController.html#workflow
Já o MultiActionController é totalmente diferente, não está relacionado com um formulário. Dá até pra fazer binding também, mas não é binding de dados de um formulário. Ele, por exemplo, não diferencia uma submissão (normalmente método post) de uma requisição de formulário (normalmente get). É isso que precisa entender. Senão vai achar que tudo isso é loucura mesmo por serem tão diferentes. No Struts, por ex, os controller são todos iguais, independente de trabalhar ou não com formulário. O que muda é um raios de ActionForm associado no struts-config.xml.
Então, o que vc deve estar sentido falta no Spring é um controller que trabalhe com Form e ao mesmo tempo trabalhe com vários métodos como no MultiActionController, que é justamente a solicitação colocada no JIRA.
Bom, para te ajudar enquanto não tem nada igual, como o command é o mesmo, sobreescreva o onSubmit() do SimpleFormController, faça a injeção de um MethodNameResolver, e use-o para determinar o método a ser chamado dentro do seu único Controller de acordo com a URL ou algum parametro.
Pode ser que tenha outra utilização, mas seria um pé no saco para um CRUD vc ter 3 ou 4 Controllers.
Acho que comeram bola nessa questão e espero que a solicitação do Jira seja atendida
[/quote]
Bom, para te ajudar enquanto não tem nada igual, como o command é o mesmo, sobreescreva o onSubmit() do SimpleFormController, faça a injeção de um MethodNameResolver, e use-o para determinar o método a ser chamado dentro do seu único Controller de acordo com a URL ou algum parametro.
[/quote]
Já trabalho em alguns casos dessa maneira, e sinceramente não gosto muito.
Quando o projeto começa a crescer, você sente que tem muitos controllers e tarefa repetitiva demais.
)
