Google Guice vs. PicoContainer per Dependency Injection

Il mio team sta ricercando framework di iniezione delle dipendenze e sta cercando di decidere tra l'utilizzo di Google-Guice e PicoContainer.

Stiamo cercando diverse cose nel nostro framework:

1. Una piccola impronta di codice - Quello che intendo per una piccola impronta di codice è che non vogliamo avere rifiuti di codice di iniezione di dipendenza ovunque nella nostra base di codice. Se dobbiamo eseguire il refactoring lungo la strada, vogliamo che sia il più semplice possibile.
2. Prestazioni: quanto overhead ha ogni framework durante la creazione e l'inserimento di oggetti?
3. Facilità di utilizzo - C'è una grande curva di apprendimento? Dobbiamo scrivere montagne di codice per far funzionare qualcosa di semplice? Vogliamo avere la minor configurazione possibile.
4. Dimensioni della comunità: comunità più grandi di solito significano che un progetto continuerà a essere mantenuto. Non vogliamo utilizzare un framework e dobbiamo correggere i nostri bug;) Inoltre, qualsiasi domanda che abbiamo lungo il percorso può (si spera) trovare risposta dalla comunità di sviluppatori / utenti del framework.

Sarebbe molto apprezzato il confronto dei due quadri con i criteri elencati. Anche qualsiasi esperienza personale che aiuti a confrontare i due sarebbe estremamente utile.

Dichiarazione di non responsabilità: sono abbastanza nuovo nell'iniezione di dipendenza, quindi scusa il mio non-essere se ho posto una domanda che non è pertinente a questa discussione.

Potresti voler includere Spring nell'elenco dei framework di Dependency Injection che stai prendendo in considerazione. Ecco alcune risposte alle tue domande:

Accoppiamento al quadro

Pico - Pico tende a scoraggiare l'iniezione di setter, ma a parte questo, le tue classi non hanno bisogno di sapere di Pico. È solo il cablaggio che deve sapere (vero per tutti i framework DI).

Guice - Guice ora supporta le annotazioni JSR 330 standard , quindi non sono più necessarie annotazioni specifiche Guice nel codice. Spring supporta anche queste annotazioni standard. L'argomento usato dai ragazzi di Guice è che senza un processore di annotazioni Guice in esecuzione, questi non dovrebbero avere un impatto se decidi di utilizzare un framework diverso.

Spring - Spring mira a consentire di evitare qualsiasi menzione del framework Spring nel codice. Poiché hanno molti altri helper / utilità ecc., La tentazione è piuttosto forte di dipendere dal codice Spring, però.

Prestazione

Pico - Non ho molta familiarità con le caratteristiche di velocità di Pico

Guice - Guice è stato progettato per essere veloce e il confronto menzionato nella referenza ha dei numeri. Certamente, se la velocità è una considerazione primaria, è opportuno considerare l'uso di Guice o il cablaggio manuale

Primavera : la primavera può essere lenta. C'è stato del lavoro per renderlo più veloce e l'uso della libreria JavaConfig dovrebbe accelerare le cose.

Facilità di utilizzo

Pico - Semplice da configurare. Pico può prendere alcune decisioni sui cavi automatici per te. Non è chiaro come si ridimensiona a progetti molto grandi.

Guice - Semplice da configurare, devi solo aggiungere annotazioni ed ereditare da AbstractModule per legare le cose insieme. Si adatta bene a progetti di grandi dimensioni poiché la configurazione è ridotta al minimo.

Spring : relativamente facile da configurare, ma la maggior parte degli esempi utilizza Spring XML come metodo di configurazione. I file XML Spring possono diventare molto grandi e complessi nel tempo e richiedere tempo per il caricamento. Prendi in considerazione l'utilizzo di una miscela di Spring e iniezione di dipendenza a manovella per superare questo problema.

Dimensione della comunità

Pico - Piccolo

Guice - Medio

Primavera - Grande

Esperienza

Pico - Non ho molta esperienza con Pico ma non è un framework ampiamente utilizzato, quindi sarà più difficile trovare risorse.

Guice - Guice è un framework popolare e la sua attenzione alla velocità è benvenuta quando hai un progetto di grandi dimensioni che stai riavviando molto in fase di sviluppo. Ho una preoccupazione per la natura distribuita della configurazione, cioè non è facile vedere come è messa insieme l'intera applicazione. È un po 'come l'AOP sotto questo aspetto.

Primavera - La primavera è solitamente la mia scelta predefinita. Detto questo, l'XML può diventare macchinoso e il conseguente rallentamento fastidioso. Spesso finisco per usare una combinazione di Dependency Injection e Spring artigianali. Quando hai effettivamente bisogno di una configurazione basata su XML, Spring XML è abbastanza buono. Spring si è impegnata molto anche per rendere altri framework più compatibili con l'inserimento delle dipendenze, il che può essere utile perché spesso utilizzano le migliori pratiche quando lo fanno (JMS, ORM, OXM, MVC ecc.).

Riferimenti

• Pico
• Guice
• Primavera
• Confronto primavera / Guice / Pico
• Un altro confronto delle prestazioni di Spring / Guice

La risposta fornita da jamie.mccrindle è in realtà piuttosto buona, ma sono rimasto confuso sul motivo per cui Spring è la scelta predefinita quando è abbastanza chiaro che sono disponibili alternative superiori (sia Pico che Guice). La popolarità di IMO Spring ha raggiunto il suo apice e ora sta attualmente vivendo del clamore generato (insieme a tutti gli altri sottoprogetti di primavera "anche io" che cercano di cavalcare il carro della primavera).

L'unico vero vantaggio della primavera è la dimensione della comunità (e francamente, a causa delle dimensioni e della complessità, è necessaria), ma Pico e Guice non hanno bisogno di una grande comunità perché la loro soluzione è molto più pulita, più organizzata e più elegante. Pico sembra più flessibile di Guice (puoi usare le annotazioni in Pico o no - è estremamente efficiente). (Modifica: intendeva dire che è estremamente flessibile, non che non sia anche efficiente.)

Le dimensioni ridotte di Pico e la mancanza di dipendenze sono una vittoria PRINCIPALE che non dovrebbe essere sottovalutata. Quanti mega devi scaricare per usare Spring adesso? È un pasticcio di enormi file jar, con tutte le sue dipendenze. Pensando in modo intuitivo, una soluzione così efficiente e "piccola" dovrebbe scalare e funzionare meglio di qualcosa come Spring. Il gonfiore della primavera lo farà davvero scalare meglio? È questo mondo bizzarro? Non darei per scontato che Spring sia "più scalabile" fino a quando non sarà provato (e spiegato).

A volte creare qualcosa di buono (Pico / Guice) e poi tenerlo lontano da esso invece di aggiungere funzioni gonfie e lavello da cucina con infinite nuove versioni funziona davvero ...

NOTA: questo è più un commento / rant che una risposta

PicoContainer è fantastico. Ritornerei ad esso se solo sistemassero i loro siti web. È davvero confuso ora:

• http://picocontainer.com che è il più recente, ma molte pagine hanno problemi di formattazione e alcune pagine non funzionano affatto. Sembra che le pagine siano state convertite automaticamente dal contenuto precedente.
• http://picocontainer.codehaus.org/ Che sembra congelato nel tempo alla versione 2.10.2 - Sarebbe davvero bello se le pagine dicessero qualcosa come "ehi, stai guardando un vecchio sito web!"
• http://docs.codehaus.org/display/PICO/Home - Un wiki di confluenza che documenta la v 1.x, ma non lo dice da nessuna parte sulle pagine!

Sto usando Guice 2.x ora, anche se è più grande e ha meno funzioni. È stato molto più facile trovare la documentazione e il suo gruppo di utenti è molto attivo. Tuttavia, se la direzione di Guice 3 è indicativa, sembra che Guice stia iniziando a gonfiarsi, proprio come la primavera nei primi giorni.

Aggiornamento: ho pubblicato un commento ai ragazzi di Pico Container e hanno apportato alcuni miglioramenti al sito web. Molto meglio ora!

È una vecchia domanda ma oggi puoi considerare Dagger ( https://github.com/square/dagger ) nel tuo progetto di app Android. Dagger genera codice durante la compilazione. In questo modo si ottiene un tempo di avvio più breve e un minore utilizzo della memoria durante il tempo di esecuzione.

Se stai cercando un contenitore DI minimalista, puoi dare un'occhiata a Feather . Funzionalità solo Vanilla JSR-330 DI, ma abbastanza buona in termini di footprint (16K, nessuna dipendenza) e prestazioni. Funziona su Android.

Anche se mi piace PicoContainer per la sua semplicità e per la mancanza di dipendenze. Consiglierei invece di usare CDI perché fa parte dello standard Java EE, quindi non hai vincoli al fornitore.

In termini di invadenza, il problema principale è il requisito di un contenitore e l'uso di un file META-INF / bean.xml relativamente vuoto (necessario per indicare che il jar utilizza CDI) e l'uso di annotazioni (sebbene siano standard )

Il container CDI leggero che utilizzo per i miei progetti è Apache Open Web Beans. Anche se ci è voluto un po 'per capire come creare un'app semplice (a differenza di Pico) che assomiglia a questa.

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();
}