Google Guice vs JSR-299 CDI/Weld

Question

Weld, l'implementazione di riferimento JSR-299 Contesti e Iniezione delle dipendenze, si considera una sorta di successore di Spring e Guice.

CDI è stato influenzato da un numero di framework Java esistenti, tra cui Seam, Guice e Spring. Tuttavia, CDI ha il suo carattere molto distinto: più sicuro di Seam, più statico e meno XML-centrico di Spring, più capace di applicazioni Web e enterprise rispetto a Guice. Ma non poteva essere uno di questi senza l'ispirazione dalle strutture menzionate e molta collaborazione e duro lavoro da parte del JSR-299 Expert Group (EG).

http://docs.jboss.org/weld/reference/latest/en-US/html/1.html

Ciò che rende più capace di saldatura per l'applicazione enterprise rispetto a Guice? Ci sono vantaggi o svantaggi rispetto a Guice? Cosa ne pensi di Guice AOP rispetto agli intercettori di Saldatura? Che dire delle prestazioni?

mia scelta

Alla fine ho deciso di utilizzare Guice perché mi piace il modello di programmazione pulita che viene quasi senza annotazioni oltre @Inject per impostazione predefinita. È molto più facile usare librerie esterne con Guice che con CDI. AOP è anche abbastanza semplice con Guice.

Answer 1

CDI (Weld) non è stato ancora utilizzato ampiamente, quindi è difficile effettuare un confronto. Alcuni punti:

• CDI è stato progettato con l'integrazione con EJB3, JSF e altri standard JavaEE in mente. CDI ha le cosiddette estensioni portatili che consentono alle librerie di terze parti di integrarsi con il ciclo di vita e il funzionamento interno di un'implementazione CDI
• CDI è stato progettato pensando a tutti i possibili casi d'angolo, quindi è probabile che copra tutto ciò di cui hai bisogno . Spring, Guice e Seam si sono evoluti in tale stato, mentre CDI utilizza l'esperienza di questi tre.
• a mio parere, gli intercettori CDI non saranno in grado di soddisfare tutte le richieste che Spring AOP ha incontrato. Forse lo stesso vale per Guice AOP. Non è possibile definire un intercettore usando la sintassi di AspectJ.
• la mancanza di definizioni xml è sia un vantaggio che uno svantaggio e alcune persone (giustamente in alcuni casi) preferiscono la configurazione xml.
• l'uso esteso delle annotazioni dei qualificatori (a mio parere) genererà alcuni grossi problemi se non utilizzati con attenzione.

Answer 2

Prima di provare a rispondere alla tua domanda, vorrei solo aggiungere un pezzo importante di informazioni: JSR 330 (@Inject) è stato standardizzato dal Guice e progetti di primavera (announcement from May 2009) ed è in fase reused in JSR 299. Questo copre i meccanismi DI di base in termini di dichiarazione di un punto di iniezione.

Ora, torniamo alla domanda - con il disclaimer che ho molta più esperienza con Spring che con Guice.

funzionalità Enterprise in Weld

• Alternative configuration mechanisms hanno un design molto pulito in JSR-299 e consentono di meccanismi di configurazione al di fuori del codice Java (beans.xml).
• Events sono una cosa molto potente e si adattano bene con JMS. Ho appena trovato un Event Bus for Guice, ma non posso dire come questo paragoni.
• Portable extensions sono un SPI che può essere utilizzato per l'integrazione con la tecnologia esistente o per avvolgere il codice legacy in modo pulito.

vantaggi/svantaggi

Nota: cercherò di aggiungere alcuni elementi qui più tardi, ma questa risposta è già più di quanto mi aspettassi, mi dispiace.

• Weld/CDI

  • Standardizzazione: Se qualcosa è standardizzato e non v'è una buona implementazione, un sacco di gente verrà utilizzato. Esempio: Built-in scopes in Weld fornisce alcuni altri ambiti oltre a Guice o Spring. Tutti questi possono essere estesi, ma i framework applicativi si baseranno piuttosto su ambiti standard se sono utilizzati da una grande comunità.
  • Supporto contenitore: simile all'elemento precedente, ma un argomento importante per l'adozione. I principali server di applicazioni open source, come Glassfish e JBoss 6, forniscono supporto CDI (vedere here).

• Guice/primavera

  • applicazione effettiva: La maggior parte delle applicazioni esistenti verrà utilizzato già Guice/primavera. Spring/Guice si è sempre basata sugli standard e ha fornito nuove funzionalità in cui non esistevano standard o non potevano essere utilizzati. Se segui le rispettive best practice, il framework ti aiuterà a rendere la tua applicazione basata su standard e pulita.

AOP e intercettori

Questo è un argomento molto discusso pesantemente, e non può favorire uno sopra l'altro. Entrambi i meccanismi sono molto potenti ma richiedono almeno una minima comprensione dell'architettura dell'applicazione. Anche dare un'occhiata a Decorators e il riferimento Events. È meglio andare con lo strumento giusto, ma non dimenticare che se uno sviluppatore deve lavorare con uno di questi meccanismi è una buona cosa se lui/lei capisce il concetto.

prestazioni

Purtroppo non ho potuto guardare in questo ancora, ma ci sono alcune regole che cerco di seguire, soprattutto quando si utilizza un framework che ti dà un sacco di funzionalità senza di te se ne accorgesse:

• Quando possibile, preferire un singolo passaggio di cablaggio su più ricerche in fase di esecuzione.
• Se possibile, eseguire tutti i collegamenti durante l'inizializzazione dell'applicazione.
• Qualsiasi passaggio di intercettazione o proxy AOP aggiunge alcune chiamate di metodo allo stack.

Answer 3

Un altro elemento di differenziazione è che CDI è molto orientato a Java EE. Fornisce un meccanismo alla colla i diversi sottosistemi Java EE insieme.

Ie. Annotando un bean con @Named("book"), il bean diventa noto in EL (Expression Language) unificato come "book".

Quindi è possibile utilizzare in una pagina JSF per esempio:

<h:outputLabel value="Book title:" for="bookTitle"/> 
    <h:outputText id="bookTile" value="#{book.title}"/> 

Answer 4

La caratteristica più importante CDI è opposto a Guice, è che è uno standard parte di Java EE 6.

L'importanza di questo non può essere sottovalutata, poiché significa che il CDI è lo standard DI che è necessario utilizzare per la codifica delle applicazioni Web.

Un po 'indietro ho dato un'occhiata alle tecnologie per essere in grado di determinare come potremmo avere una distribuzione core standard - opportunamente preparata - dove potremmo aggiungere a piacere moduli aggiuntivi che potrebbero scavalcare le funzionalità esistenti senza dover cambiare il core moduli. Cioè aggiungi un barattolo extra e la funzionalità si attiva automaticamente.

Si è scoperto che il modo migliore per fare questo per un codice di base utilizzato in entrambe le applicazioni desktop e web era utilizzare le annotazioni JSR-330 per il nostro codice e quindi utilizzare CDI o Guice (SVN, in arrivo vero presto ora in 3.0) come il motore.

Dopo alcuni progetti ho scoperto che mi piace la configurazione di Guice al posto della magia opaca che si verifica in Weld. Inoltre ho trovato che il modo di fare ciò che vogliamo come descritto sopra con Weld, devo contrassegnare la classe nel jar extra come @Alternative, e quindi menzionare in beans.xml che voglio la classe alternativa applicata (e che non è robusto contro il refactoring).

Ma, tutto sommato, JSR-330 ci permette di fare qualcosa che prima era molto noioso e fragile (perché lo new si lega così strettamente), e questa è una grande vittoria. Consiglio vivamente di cercare in DI se hai bisogno di questo tipo.

Answer 5

CDI for Guice users è un bel confronto.