:: Google Guice, Google DI Framework

Assuntos Gerais Notícias
#1

Google lançou seu framework de DI chamado Guice, que faz uso de anotações e generics. Ele nao usa XML e injeta os serviços de várias formas… Tem suporte a Spring, Struts 2, AOP, circular dependencies, custon scopes, etc.

Quem vai gostar é o pessoal do Mentawai: NO XML’s…

Bom, aqui vai o site deles: http://code.google.com/p/google-guice/

Será que vai começar uma flame war aqui ?

  • “Spring é melhor!!!”
  • “E vou casar com o Spring!!!”
  • etc, etc, etc…

As verdadeiras perguntas são: O que isso muda pra vc? Quando o Guice se faz util? O que ele acrescenta ao universo Java?

#2

Só faltou um exemplo no site lá… Um HelloWorld…

Se vc conseguir algum exemplo aí posta aqui para a gente ver…

#3

Exemplos estão aqui: http://docs.google.com/Doc?id=dd2fhx4z_5df5hw8

Classe de módulo que configura o, humm… , o módulo.

public class MyModule extends AbstractModule {
  protected void configure() {
    bind(Service.class)
      .to(ServiceImpl.class)
      .in(Scopes.SINGLETON);
  }
}

E a classe que utilizará o serviço:

public class Client {

  private final Service service;

  @Inject
  public Client(Service service) {
    this.service = service;
  }

  public void go() {
    service.go();
  }
}
#4

Apenas para termos algo com o que compará-lo, abaixo segue um exemplo idêntico com o Mentawai:

(Se alguém quiser colocar um exemplo usando Spring, Struts, etc. seria bom tb)

public class MyAppManager extends ApplicationManager {
  
   public void init(Context application) {

      ioc("myService", ServiceImpl.class, APPLICATION);

   }
  
   public void loadActions() {
    
      filter(new IoCFilter());
      filter(new InjectionFilter());

   }

 }

public class MyAction extends BaseAction {

    private Service myService;

    public String execute() throws Exception {

        myService.go();

        return SUCCESS;

    }
}

Uma diferença que eu vi é que eles estão fazendo injection via construtor. Com o Mentawai vc pode fazer injection via setter ou diretamente no campo privado como o exemplo acima, ou seja, sem qualquer setter.

Eles suportam injection diretamente em campo privado também? (Devem suportar…)

#5

Olá,

Ontem eu estava conversando com o Plentz sobre o framework. Sinceramente achei legal, mas nao gostei desse AbstractModule. Tem um cheiro ruim esse negocio. :stuck_out_tongue:

]['s

#6

Sérgio, calma :smiley:

o Guice não é um concorrente do mentawai …
ele é só um container para DI …
e como container para DI ele é muito mais flexivel que o mentawai, ele suporta injeção via setter e constructor.

tem um suporte muuuiittoooo fraco a AOP, e não tem absolutamente nada a ver com MVC nem web, é só infra mesmo …

uma coisa legal que achei nele, foi a possibilidade de fazer o seguinte:

[code]@ImplementedBy(ServiceImpl.class)
public interface Service {
void go();
}

@Singleton
public class ServiceImpl implements Service {
public void go() {
…
}
}
[/code]

assim se tu tiver isto:

[code]public class Client {

private final Service service;

@Inject
public Client(Service service) {
this.service = service;
}

public void go() {
service.go();
}
}[/code]
não precisa configurar no binder quem é que implementa Service …

outra coisa bem legal é poder fazer o seguinte:

bind(Service.class) .annotatedWith(Blue.class) .to(BlueService.class);

que seria injetado em algo assim:

@Inject void injectService(@Blue Service service) { ... }

ou então isto:

[code]class Mixer {

@Inject
Mixer(Concrete concrete) {
…
}
}[/code] ele cria automagicamente um objeto da classe “concrete” e injeta uma instancia dela ali.

isto foi o que ja deu tempo de eu ver do Guice …
tem algumas coisinhas que não achei legais nele também, mas isto fica pra outra hora …

#7

[quote=fabgp2001] Olá,

Ontem eu estava conversando com o Plentz sobre o framework. Sinceramente achei legal, mas nao gostei desse AbstractModule. Tem um cheiro ruim esse negocio. :stuck_out_tongue:

]['s[/quote]
<modo espero que ninguém saiba do que to falando>
abstract module não tem cheiro ruim, classes com todos os métodos static, implementando regra de negócio com dados apenas em memória sem suporte a transações, em que a unica forma de se criar um vo é inserindo dados no “banco em memória sem suporte a transações”, e com todas as classes que não são puramente estáticas tem construtores package private tornando quase impossível se criar um mock para escrever os testcases.

é que tem um cheiro estranho.
</modo espero que ninguem saiba do que to falando>

#8

To calmo. Como falei apenas dei um exemplo para “ter com o que comparar”.

Claro que não é concorrente. O Guice é genérico para ser usado com qualquer tipo de aplicaçao (web, distribuída, etc). Já o IOC/DI do Mentawai é do Menta para o Menta.

Vc quer dizer mais genérico e não mais flexível. O Mentawai suporta injeçao por construtor, setter e tb direto no campo privado. Parece que é tão flexível quanto o Guice. Só não é mais genérico pois como eu falei é do menta para o menta.

O fato do mentawai oferecer um bom suporte a IOC e DI faz com que as coisas fiquem muito mais simples. O que é mais fácil: usar um framework para web e DI ou dois frameworks: um para web e outro para DI?

A resposta é subjetiva, mas acredito que usando um framework só que já te oferece todas as principais soluções vai facilitar a vida. Nada te impede de usar tb 10 frameworks num projeto, se vc domina bem esses 10 frameworks.

#9

[quote=urubatan]
<modo espero que ninguém saiba do que to falando>
abstract module não tem cheiro ruim, classes com todos os métodos static, implementando regra de negócio com dados apenas em memória sem suporte a transações, em que a unica forma de se criar um vo é inserindo dados no “banco em memória sem suporte a transações”, e com todas as classes que não são puramente estáticas tem construtores package private tornando quase impossível se criar um mock para escrever os testcases.

é que tem um cheiro estranho.
</modo espero que ninguem saiba do que to falando>[/quote]

Quem dera se fosse só isso que tivesse cheiro ruim. :smiley:

Mas voltando não é tao feio, so nao gosto da ideia de ter que criar um módulo pra fazer essa configuração. Ta certo que nao é obrigatorio.

]['s

#10

Ai eu concordo com o Urubatan. Comparar pessego com manga nao é algo bom. :smiley:

O ideia seria uma comparacao com Pico e Spring.

]['s

#11

Certa resposta! :slight_smile:

Spring best java framework ftw

#12

Acho que a comparaçao foi pertinente. Ambos fazem a mesma coisa, só que o Guice é um framework genérico para DI e o Mentawai um framework web que suporta também DI.

Os códigos ficaram até bem parecidos… :slight_smile:

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

#13

Mas hein?

#14

[quote=Leozin][quote=Hal Jordan]

  • “Spring é melhor!!!”
    [/quote]

Certa resposta! :slight_smile:

Spring best java framework ftw[/quote]

Eu sabia, Eu sabia, Eu sabia… hahaha… Que ia ter um comentário sobre o Spring…

A questão não é o Spring, e sim o Guice… qq ele pode trazer pros seus projetos???.. Se eu precisar somente IoC/DI o Guice se mostrou um framework compentente, simples. Bem mais simples q o Spring…

Mas agora se eu preciso de controle de transações, segurança, etc… (q não é o foco do Guice) eu prefiro o Sp… EJB3.

Enfim, a questao nao é comparar o full set do Spring, mas sim o DI, q pelo jeito o Guice tá se monstrando bem simples…

#15

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!!!

#16

O P e o T ficam muito proximos. :stuck_out_tongue:

#17

[quote=Hal Jordan][quote=saoj]

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

[/quote]

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!!! [/quote]

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”:

ioc("myService", ServiceImpl.class, APPLICATION);

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:


ioc("myService", ServiceImpl.class, APPLICATION);
ioc("myServiceAgain", ServiceImpl.class, APPLICATION);

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…

#18

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.

#19

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

#20

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:


private Connection connection;

private BookDAO bookDAO;

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


ioc("bookDAO", MySQLBookDAO);

private BookDAO bookDao;

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