:: Google Guice, Google DI Framework

Hal Jordan wrote:Mas a comparação com o String é meio dificil, deixo isso como tarefa pra evangelistas!!!

O P e o T ficam muito proximos.

Hal Jordan wrote:

saoj wrote:

Alguém ai poderia colocar comparativos com Pico e String também.

Spring tá aqui : http://code.google.com/p/google-guice/wiki/SpringComparison

Mas a comparação com o String é meio dificil, deixo isso como tarefa pra evangelistas!!!

Acho que eles foram bastante políticos na comparação com Spring. O que pareceu é que eles estão falando entrelinhas que "O Guice é mais simples que o Spring".

Mencionam tb o fato do Spring ter muito XML. Não acredito que nessa altura do campeonato o Spring ainda não tenha uma configuração programática como o Guice e como o Mentawai. Alguns vão dizer que preferem XML. Ok! Gosto não se discute, mas foi bom ver que os caras do Google também gostam de configuração programática.

Outra observação interessante é que eles defendem o uso de annotations. Eu ainda estou me definindo sobre isso, mas acredito que annotation é intrusivo. Se vc tem um modelo de dados que recebe um DAO, vc pode colocar uma annotation no campo do DAO para dizer que ele vai receber a implementação vai IOC. Mas vc não estaria atrelando o seu modelo a annotation do container de IOC ???

O que o Mentawai faz é usar o nome da propriedade para definir a dependencia, ou seja, quando eu defini o IOC eu associei um nome a ele, no caso "myService":

Logo não precisa de annotation pois o InjectionFilter vai ver que o nome da propriedade da action é "myService" e vai procurar por uma implementação de Service com o nome "myService".

A única desvantagem pequena disso é que se vc tem duas classes com duas propriedades com nomes diferentes, vc vai precisar definir o IOC duas vezes:

Usando as boas práticas de organização, o seu serviço pode e deve ter o mesmo nome em todos os lugares que ele aparece na sua aplicação. Caso contrário, ter que definir duas vezes como foi feito acima tb não me parece nada demais...

Sérgio, a parte ruim de definir IoC da forma como o Mentawai e o Spring fazem, que é usando uma tonelada de strings para definir os injection points, é que acopla demais a lógica de wiring com detalhes do modelo. Se trocar o nome do atributo, tanto Spring e Mentaway vão fazer a coisa errada, usando annotations você evita isso.

Também concordo com você que é um problema usar annotations no modelo, pois ele passa a depender do framework. Tudo é uma questão de tradeoff. Qual você está pronto para aceitar.

Pessoalmente acho que Annotations são menos problemáticas, já que as classes injetadas possuem uma dependencia implicita no container de DI, pois não funcionam sem alguém exercendo esse papel. Então, com annotations diminui a quantidade de configuração e conhecimento que teu container tem sobre as classes injetadas, o que me parece sadio.

louds wrote:Se trocar o nome do atributo, tanto Spring e Mentaway vão fazer a coisa errada, usando annotations você evita isso.

No caso do Spring tem a opcao de escolher o tipo de wiring que será usado. Esse problema so ocorre quando wiring "byName" é usado o que não é aconcelhado pelo pessoal do Spring. Claro se nao usar ele a quantidade de configuracao cresce muito.

]['s

Eu diria que vc raramente vai trocar o nome do atributo, mas concordo que é um trade off, da mesma maneira que é um trade off atrelar o modelo ao framework usando annotation.

Como vc falou é uma questão de escolher qual trade off vc prefere.

Eu pessoalmente acho que nome de variável raramente muda:

Mas se por exemplo se vc fizer um typo no nome da variável, ou seja:

Não vai funcionar e vc vai ter que debugar isso... Mas typo é typo né?

fabgp2001 wrote: No caso do Spring tem a opcao de escolher o tipo de wiring que será usado. Esse problema so ocorre quando wiring "byName" é usado o que não é aconcelhado pelo pessoal do Spring. Claro se nao usar ele a quantidade de configuracao cresce muito.
]['s

Cara, na real todo mundo usa wiring "byName" e dificilmente auto-wire, eu nunca vi um projeto Spring que não fosse todo com wiring-by-name.

Minha maior birra com Spring era o tamanho monstruoso do xml, mas agora com o 2.0 isso mudou muito.

louds wrote:

fabgp2001 wrote: No caso do Spring tem a opcao de escolher o tipo de wiring que será usado. Esse problema so ocorre quando wiring "byName" é usado o que não é aconcelhado pelo pessoal do Spring. Claro se nao usar ele a quantidade de configuracao cresce muito.
]['s

Cara, na real todo mundo usa wiring "byName" e dificilmente auto-wire, eu nunca vi um projeto Spring que não fosse todo com wiring-by-name.

Pois é, eu ja vi e é um saco de trabalhar. O ponto que eu quiz tocar nem foi se usam ou nao, mas sim que há a opcao. Claro que a facilidade do "byName" nao tem comparacao.

]['s

Acho que a parte boa de utilizar Spring, é que você pode tirar proveito de outros módulos, como mvc, aop, hibernate entre outros.

Aí você começa a sentir que o projeto tem um ganho legal, apesar dos XMLs de configuração.

Estou começando a estudar o SEAM e como a integração com o Spring poderia beneficiar meu projeto.

Kenobi wrote:apesar dos XMLs de configuração.

Poxa cara eu não vejo isso como algo ruim, pelo contrário, acredito que XML veio muito mais pra facilitar do que pra "piorar a vida" do desenvolvedor. Eu prefiro mil vezes fazer gerenciamento/configurações de transações e aop pelo Spring (declarativo) do que ter que fazer na mão ou annotations todos os códigos. Sim, há lugares que as anotações caem muito bem (vide hibernate3/ejb3) até mesmo as transações declarativas @Transaction, mas pra mim XML é muito necessário em várias casos

E que tal configurar o Spring programaticamente?

http://blog.interface21.com/main/2006/11/28/a-java-configuration-option-for-spring/

Leozin wrote:
Poxa cara eu não vejo isso como algo ruim, pelo contrário, acredito que XML veio muito mais pra facilitar do que pra "piorar a vida" do desenvolvedor.

Kra, sei lah, XML normalmente dá mais problema do que solução.

Quando c escreve algo errado no XML, normalmente vai dar um erro em Runtime que não tem nada a ver com o problema.

Eu ainda axo q a cada dia mais e mais projetos estão fugindo do XML.

Pode ser viagem minha, mas eu fujo do XML o tanto quanto possível!

VELO

class MeuXyz extends AbsctractXyz??!?

É sério que as pessoas ainda constroem frameworks onde os módulos não são POJOs?

pcalcado wrote:class MeuXyz extends AbsctractXyz??!?

É sério que as pessoas ainda constroem frameworks onde os módulos não são POJOs?

Mas ai daonde viriam os metodos para configurar as coisas?

Soh se fosse assim:

A unica vantagem seria que o modulo nao extenderia ninguem, mas do mesmo jeito ele ficaria dependente do framework...

Vale a pena isso?

Opções...

1 - Como o Spring faz
2 - Convention over configuration no nome dos métodos, exceção tratada com uma anotação, acho que é o que o VRaptor faz

pcalcado wrote:
1 - Como o Spring faz

Nao tenho ideia...

pcalcado wrote:
2 - Convention over configuration no nome dos métodos, exceção tratada com uma anotação, acho que é o que o VRaptor faz

Para o metodo configure() sem problemas. Mas dentro desse metodo vc vai ter que chamar outros metodos para configurar a coisa, e esses metodos tem que vir de algum lugar. CoC nao resolve aqui...

Acho que soh tem duas opcoes:

1 - Estende uma classe abstrata.

2 - Passa um Configurator como parametro de configure().

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