Google Guice vs. PicoContainer para injeção de dependência

Minha equipe está pesquisando frameworks de injeção de dependência e está tentando decidir entre usar o Google-Guice e o PicoContainer.

Estamos procurando várias coisas em nossa estrutura:

1. Uma pequena pegada de código - o que quero dizer com uma pequena pegada de código é que não queremos ter código de injeção de dependência em toda parte em nossa base de código. Se precisarmos refatorar no futuro, queremos que seja o mais fácil possível.
2. Desempenho - quanta sobrecarga cada estrutura tem ao criar e injetar objetos?
3. Facilidade de uso - existe uma grande curva de aprendizado? Precisamos escrever montes de código para fazer algo simples funcionar? Queremos ter o mínimo de configuração possível.
4. Tamanho da comunidade - Comunidades maiores geralmente significam que um projeto continuará a ser mantido. Não queremos usar um framework e temos que consertar nossos próprios bugs;) Além disso, quaisquer perguntas que tenhamos ao longo do caminho podem (espero) ser respondidas pela comunidade de desenvolvedores / usuários do framework.

As comparações das duas estruturas com os critérios listados seriam muito apreciadas. Quaisquer experiências pessoais que ajudem a comparar os dois também seriam extremamente úteis.

Isenção de responsabilidade: eu sou bastante novo em injeção de dependência, então desculpe meu noob-ness se eu fiz uma pergunta que não seja pertinente a esta discussão.

Você pode querer incluir Spring em sua lista de frameworks de injeção de dependência que está considerando. Aqui estão algumas respostas às suas perguntas:

Acoplamento à estrutura

Pico - O Pico tende a desencorajar a injeção de setter, mas fora isso, suas classes não precisam saber sobre o Pico. É apenas a fiação que precisa saber (verdadeiro para todas as estruturas de DI).

Guice - o Guice agora suporta as anotações JSR 330 padrão , então você não precisa mais de anotações específicas do Guice em seu código. Spring também suporta essas anotações padrão. O argumento que os caras do Guice usam é que, sem um processador de anotações do Guice em execução, eles não deveriam ter um impacto se você decidir usar um framework diferente.

Spring - Spring visa permitir que você evite qualquer menção ao framework Spring em seu código. Como eles têm muitos outros ajudantes / utilitários, etc., a tentação de depender do código do Spring é muito forte.

atuação

Pico - Não estou muito familiarizado com as características de velocidade do Pico

Guice - O Guice foi desenhado para ser rápido e a comparação mencionada na referência tem alguns números. Certamente, se a velocidade é uma consideração primária, tanto o uso do Guice quanto a fiação manual deve ser considerada

Primavera - a primavera pode ser lenta. Tem havido trabalho para torná-lo mais rápido e usar a biblioteca JavaConfig deve acelerar as coisas.

Fácil de usar

Pico - Simples de configurar. Pico pode tomar algumas decisões de autowire para você. Não está claro como ele se adapta a projetos muito grandes.

Guice - Simples de configurar, basta adicionar anotações e herdar de AbstractModule para vincular as coisas. Escala bem para grandes projetos, pois a configuração é reduzida ao mínimo.

Spring - relativamente fácil de configurar, mas a maioria dos exemplos usa Spring XML como método de configuração. Os arquivos Spring XML podem se tornar muito grandes e complexos com o tempo e demorar para carregar. Considere o uso de uma combinação de injeção de dependência de mola e manivela para superar isso.

Tamanho da comunidade

Pico - Pequeno

Guice - Médio

Primavera - Grande

Experiência

Pico - Não tenho muita experiência com o Pico, mas não é um framework amplamente utilizado, então será mais difícil encontrar recursos.

Guice - Guice é um framework popular e seu foco na velocidade é bem-vindo quando você tem um grande projeto que está reiniciando muito em desenvolvimento. Tenho uma preocupação com a natureza distribuída da configuração, ou seja, não é fácil ver como todo o nosso aplicativo é montado. É um pouco como AOP a esse respeito.

Spring - geralmente é a minha escolha padrão. Dito isso, o XML pode se tornar complicado e a desaceleração resultante irritante. Muitas vezes acabo usando uma combinação de injeção de dependência artesanal e Spring. Quando você realmente precisa de configuração baseada em XML, Spring XML é muito bom. O Spring também se esforçou para tornar outras estruturas mais amigáveis ​​à injeção de dependência, o que pode ser útil porque eles costumam usar as melhores práticas ao fazer isso (JMS, ORM, OXM, MVC etc.).

Referências

• Pico
• Guice
• Primavera
• Comparação Primavera / Guice / Pico
• Outra comparação de desempenho Spring / Guice

A resposta apresentada por jamie.mccrindle é realmente muito boa, mas fiquei confuso por que Spring é a escolha padrão quando está bastante claro que alternativas superiores (Pico e Guice) estão disponíveis. A popularidade do IMO Spring atingiu seu pico e agora está vivendo do hype gerado (junto com todos os outros subprojetos "eu também" do Spring que procuram pegar o trem do Spring).

A única vantagem real do Spring é o tamanho da comunidade (e francamente, devido ao tamanho e complexidade, é necessário), mas Pico e Guice não precisam de uma grande comunidade porque sua solução é muito mais limpa, mais organizada e mais elegante. O Pico parece mais flexível do que o Guice (você pode usar anotações no Pico, ou não - é extremamente eficiente). (Editar: quer dizer que é extremamente flexível, não que também não seja eficiente.)

O tamanho minúsculo do Pico e a falta de dependências é uma vitória PRINCIPAL que não deve ser subestimada. Quantos megas você precisa baixar para usar o Spring agora? É uma bagunça confusa de arquivos jar enormes, com todas as suas dependências. Pensando intuitivamente, uma solução tão eficiente e "pequena" deve ser dimensionada e ter um desempenho melhor do que algo como o Spring. O inchaço da primavera realmente vai torná-lo melhor escalar? É este mundo bizarro? Eu não faria suposições de que o Spring é "mais escalável" até que isso seja provado (e explicado).

Às vezes, criar algo bom (Pico / Guice) e, em seguida, manter as MÃOS FORA disso em vez de adicionar recursos de inchaço e pia de cozinha com infinitas novas versões realmente funciona ...

NOTA: Isso é mais um comentário / retórica do que uma resposta

O PicoContainer é ótimo. Eu voltaria para ele se eles apenas consertassem seus sites. É muito confuso agora:

• http://picocontainer.com que é o mais recente, mas muitas páginas têm problemas de formatação e algumas páginas não funcionam de todo. Parece que as páginas foram convertidas automaticamente do conteúdo mais antigo.
• http://picocontainer.codehaus.org/ Que parece congelado no tempo na versão 2.10.2 - Seria muito bom se as páginas dissessem algo como "ei, você está olhando para um site antigo!"
• http://docs.codehaus.org/display/PICO/Home - Um wiki de confluência que documenta a v 1.x, mas não diz isso em nenhuma parte das páginas!

Estou usando o Guice 2.x agora, embora seja maior e tenha menos recursos. Foi muito mais fácil encontrar a documentação e seu grupo de usuários é muito ativo. No entanto, se a direção do Guice 3 for qualquer indicação, parece que o Guice está começando a inchar, assim como a primavera fazia nos primeiros dias.

Atualização: Postei um comentário para o pessoal do Pico Container e eles fizeram algumas melhorias no site. Muito melhor agora!

É uma questão antiga, mas hoje você pode considerar Dagger ( https://github.com/square/dagger ) em seu projeto de aplicativo Android. Dagger gera código em tempo de compilação. Assim, você obtém um tempo de inicialização mais curto e menos uso de memória no tempo de execução.

Se você está atrás de um contêiner de DI minimalista, pode dar uma olhada no Feather . Funcionalidade Vanilla JSR-330 DI apenas, mas muito boa em termos de pegada (16K, sem dependências) e desempenho. Funciona no Android.

Embora eu goste do PicoContainer por sua simplicidade e falta de dependências. Eu recomendaria usar CDI em vez disso, porque ele faz parte do padrão Java EE, então você não tem dependência de fornecedor.

Em termos de intrusão, seu principal problema é a necessidade de um contêiner e o uso de um arquivo META-INF / beans.xml relativamente vazio (necessário para indicar que o jar está usando CDI) e o uso de anotações (embora sejam padrão )

O contêiner CDI leve que uso para meus próprios projetos é o Apache Open Web Beans. Embora tenha demorado um pouco para descobrir como criar um aplicativo simples (ao contrário do Pico) que se parece com isso.

public static void main(final String[] args) {
    final ContainerLifecycle lifecycle = WebBeansContext.currentInstance()
            .getService(ContainerLifecycle.class);
    lifecycle.startApplication(null);

    final BeanManager beanManager = lifecycle.getBeanManager();
    // replace Tester with your start up class
    final Bean<?> bean = beanManager.getBeans(Tester.class).iterator()
            .next();

    final Tester b = (Tester) lifecycle.getBeanManager().getReference(bean,
            Tester.class, beanManager.createCreationalContext(bean));
    b.doInit();
}