Google Guice vs JSR-299 CDI/Weld

Question

Weld, die JSR-299 Contexts und Dependency Injection Referenzimplementierung, versteht sich als eine Art Nachfolger von Spring und Guice.

CDI wurde von einer Reihe von Java-Frameworks beeinflusst, einschließlich Seam, Guice und Spring. CDI hat jedoch seinen eigenen, sehr unterschiedlichen Charakter: mehr typsicher als Seam, mehr Stateful und weniger XML-zentriert als Spring, mehr Web- und Enterprise-Anwendungen als Guice. Aber es konnte nicht ohne die Inspiration aus den genannten Rahmen und viel Zusammenarbeit und harte Arbeit der JSR-299 Expert Group (EG) sein.

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

Was macht Weld mehr für Enterprise-Anwendung in der Lage im Vergleich zu Guice? Gibt es irgendwelche Vorteile oder Nachteile im Vergleich zu Guice? Was denkst du über Guice AOP im Vergleich zu Weld Interceptors? Was ist mit Leistung?

Meine Auswahl

Am Ende entschied ich mich Guice zu verwenden, weil ich das sauberen Programmiermodell wie das ohne Anmerkungen neben @Inject standardmäßig fast kommt. Es ist viel einfacher, externe Bibliotheken mit Guice zu verwenden als mit CDI. AOP ist auch ziemlich einfach mit Guice.

Answer 1

CDI (Weld) ist noch nicht weit verbreitet, so dass ein Vergleich schwierig ist. Ein paar Punkte:

• CDI wurde mit Integration mit EJB3, JSF und anderen JavaEE Standards entwickelt. CDI hat die so genannten portable Extensions, die Bibliotheken von Drittanbietern erlauben, mit dem Lebenszyklus und der internen Funktionsweise einer CDI-Implementierung zu integrieren. CDI wurde mit allen möglichen Ecken-Fällen entworfen, so dass es wahrscheinlich alles abdeckt, was Sie brauchen . Spring, Guice und Seam entwickelten sich zu einem solchen Zustand, während CDI die Erfahrung aus diesen drei nutzt.
• meiner Meinung nach werden CDI-Interzeptoren nicht in der Lage sein, alle Anforderungen zu erfüllen, die Spring AOP erfüllt hat. Vielleicht dasselbe gilt für Guice AOP. Sie können einen Interceptor nicht mithilfe der AspectJ-Syntax definieren.
• das Fehlen von XML-Definitionen ist sowohl ein Vorteil als auch ein Nachteil und einige Leute (zu Recht in einigen Fällen) bevorzugen XML-Konfiguration.
• die erweiterte Verwendung von Qualifier Annotationen wird (meiner Meinung nach) einige große Verwirrungen erzeugen, wenn nicht sorgfältig verwendet.

Answer 2

Bevor Sie versuchen, Ihre Frage zu beantworten, lassen Sie mich nur eine wichtige Information hinzufügen: JSR 330 (@Inject) wurde von Guice und Spring-Projekte standardisiert (announcement from May 2009) und reused in JSR 299 zu sein. Dies deckt grundlegende DI-Mechanismen hinsichtlich der Angabe eines Injektionspunktes ab.

Nun zurück zu der Frage - mit dem Disclaimer, dass ich viel mehr Erfahrung mit Spring habe als mit Guice.

Unternehmen Fähigkeiten in Weld

• Alternative configuration mechanisms haben ein sehr klares Design in JSR-299 und außerhalb des Java-Code (beans.xml) für Konfigurationsmechanismen ermöglichen.
• Events sind eine sehr mächtige Sache und passen gut zu JMS. Ich habe gerade eine Event Bus for Guice gefunden, aber ich kann nicht sagen, wie das aussieht.
• Portable extensions sind ein SPI, das verwendet werden kann, um mit existierender Technologie zu integrieren oder Legacy-Code auf eine saubere Weise zu verpacken.

Vorteile/Nachteile

Hinweis: Ich werde versuchen, ein paar Punkte hier später hinzufügen, aber diese Antwort ist schon länger als ich erwartet hatte, sorry.

• Weld/CDI

  • Standardisierung: Wenn etwas standardisiert und es gibt eine gute Umsetzung, eine Menge Leute werden es werden. Beispiel: Built-in scopes in Weld liefern ein paar mehr Bereiche als Guice oder Spring. Alle diese können erweitert werden, aber Anwendungs-Frameworks werden sich eher auf Standardbereiche stützen, wenn sie von einer großen Community verwendet werden.
  • Container-Unterstützung: Dies ist ähnlich dem vorherigen Element, aber ein wichtiges Argument für die Annahme. Größere Open-Source-Anwendungsserver wie Glassfish und JBoss 6 bieten CDI-Unterstützung (siehe here).

• Guice/Frühjahr

  • Tatsächliche Anwendung: Die meisten der bestehenden Anwendungen werden bereits Guice/Frühjahr werden. Spring/Guice haben immer auf Standards aufgebaut und neue Funktionen zur Verfügung gestellt, wo keine Standards existierten oder nicht verwendet werden konnten. Wenn Sie die entsprechenden Best Practices befolgen, hilft Ihnen das Framework dabei, Ihre Anwendung auf Standards basierend und sauber zu machen.

AOP und Abfangjäger

Dies ist ein sehr stark diskutiertes Thema, und ich kann nicht übereinander begünstigen. Beide Mechanismen sind sehr leistungsfähig, erfordern jedoch mindestens ein minimales Verständnis der Anwendungsarchitektur. Siehe auch Decorators und die zuvor genannten Events. Es ist am besten, mit dem richtigen Werkzeug zu gehen, aber vergessen Sie nicht, dass wenn ein Entwickler mit einem dieser Mechanismen arbeiten muss, es gut ist, wenn er/sie das Konzept versteht.

Leistung

Leider konnte ich noch nicht in diese aussehen, aber es gibt ein paar Regeln, die ich versuchen, vor allem zu folgen, wenn ein Rahmen, die Sie viel Funktionalität gibt, ohne dass Sie es merken:

• Wenn möglich, bevorzugen Sie einen einzelnen Verdrahtungsschritt über mehrere Suchvorgänge zur Laufzeit.
• Wenn möglich, führen Sie die gesamte Verdrahtung bei der Anwendungsinitialisierung durch.
• Jeder Überwachungsschritt oder AOP-Proxy fügt dem Stapel einige Methodenaufrufe hinzu.

Answer 3

Ein weiteres Unterscheidungsmerkmal ist, dass CDI sehr Java EE orientiert ist. Es bietet einen Mechanismus Klebstoff die verschiedenen Java EE Subsysteme zusammen.

Ie. Durch Annotation einer Bean mit @Named("book") wird die Bean in der vereinigten EL (Expression Language) als 'book' bekannt.

Dann können Sie es in einer JSF-Seite zum Beispiel verwenden:

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

Answer 4

Das wichtigste Merkmal CDI zu Guice Gegensatz hat, ist, dass es ein Standard Teil von Java EE 6.

ist

Die Wichtigkeit dieser Option ist nicht zu unterschätzen, da CDI der DI-Standard ist, den Sie für die Codierung von Webanwendungen verwenden sollten.

Vor einiger Zeit habe ich mir die Technologien angeschaut, um zu bestimmen, wie wir eine Standard-Kerndistribution haben - passend vorbereitet - wo wir nach Belieben zusätzliche Module hinzufügen können, ohne bestehende Kernfunktionen zu ändern Module. I.e. fügen Sie ein zusätzliches Glas hinzu, und die Funktionalität wird automatisch aktiviert.

Es stellte sich heraus, dass der beste Weg für eine Codebasis in Desktop- und Webanwendungen war, JSR-330-Annotationen für unseren Code zu verwenden und dann entweder CDI oder Guice (SVN, coming) zu verwenden Echt bald in 3.0) als der Motor.

Nach ein paar Projekten habe ich festgestellt, dass ich die Guice-Konfiguration am besten mag, statt der undurchsichtigen Magie, die in Weld passiert. Zusätzlich habe ich festgestellt, dass ich wie oben beschrieben mit Weld verfahren kann. Ich muss die Klasse im Extra-Jar als @Alternative markieren und dann in beans.xml angeben, dass die alternative Klasse erzwungen werden soll (und das ist nicht der Fall) robust gegen Refactoring).

Aber alles in allem erlaubt JSR-330 uns, etwas zu tun, das vorher sehr mühsam und zerbrechlich war (weil new so extrem fest bindet), und das ist ein großer Gewinn. Ich kann dringend empfehlen, in DI zu schauen, wenn Sie solche Bedürfnisse haben.

Answer 5

CDI for Guice users ist ein schöner Vergleich.