Google Guice vs. PicoContainer für Abhängigkeitsinjektion

Mein Team erforscht Frameworks für die Abhängigkeitsinjektion und versucht, sich zwischen der Verwendung von Google-Guice und PicoContainer zu entscheiden.

Wir suchen verschiedene Dinge in unserem Rahmen:

1. Ein kleiner Code-Footprint - Was ich unter einem kleinen Code-Footprint verstehe, ist, dass wir nicht überall in unserer Codebasis Abhängigkeitsinjektionscode-Abfall haben möchten. Wenn wir die Straße später umgestalten müssen, möchten wir, dass es so einfach wie möglich ist.
2. Leistung - Wie viel Overhead hat jedes Framework beim Erstellen und Einfügen von Objekten?
3. Benutzerfreundlichkeit - Gibt es eine große Lernkurve? Müssen wir eine Menge Code schreiben, damit etwas Einfaches funktioniert? Wir wollen so wenig Konfiguration wie möglich haben.
4. Community-Größe - Größere Communities bedeuten normalerweise, dass ein Projekt weiterhin gepflegt wird. Wir wollen kein Framework verwenden und müssen unsere eigenen Fehler beheben;) Auch alle Fragen, die wir auf dem Weg haben, können (hoffentlich) von der Entwickler- / Benutzergemeinschaft des Frameworks beantwortet werden.

Vergleiche der beiden Frameworks mit den aufgeführten Kriterien wären sehr willkommen. Alle persönlichen Erfahrungen, die helfen, die beiden zu vergleichen, wären ebenfalls äußerst hilfreich.

Haftungsausschluss: Ich bin ziemlich neu in der Abhängigkeitsinjektion. Entschuldigen Sie meine Unaufrichtigkeit, wenn ich eine Frage stelle, die für diese Diskussion nicht relevant ist.

Möglicherweise möchten Sie Spring in Ihre Liste der von Ihnen in Betracht gezogenen Abhängigkeitsinjektions-Frameworks aufnehmen. Hier einige Antworten auf Ihre Fragen:

Kopplung an das Framework

Pico - Pico neigt dazu, die Setter-Injektion zu unterbinden, aber ansonsten müssen Ihre Klassen nichts über Pico wissen. Es muss nur die Verkabelung wissen (gilt für alle DI-Frameworks).

Guice - Guice unterstützt jetzt die Standard- JSR 330- Annotationen, sodass Sie keine Guice-spezifischen Annotationen mehr in Ihrem Code benötigen. Spring unterstützt auch diese Standardanmerkungen. Das Argument, das die Guice-Leute verwenden, ist, dass diese ohne einen Guice-Annotationsprozessor keine Auswirkungen haben sollten, wenn Sie sich für ein anderes Framework entscheiden.

Spring - Spring soll es Ihnen ermöglichen, das Spring-Framework in Ihrem Code nicht zu erwähnen. Da sie viele andere Helfer / Dienstprogramme usw. haben, ist die Versuchung jedoch ziemlich groß, vom Spring-Code abhängig zu sein.

Performance

Pico - Ich bin mit den Geschwindigkeitseigenschaften von Pico nicht allzu vertraut

Guice - Guice wurde entwickelt, um schnell zu sein, und der in der Referenz erwähnte Vergleich hat einige Zahlen. Wenn die Geschwindigkeit im Vordergrund steht, sollte entweder Guice oder die Verkabelung von Hand in Betracht gezogen werden

Frühling - Frühling kann langsam sein. Es wurde daran gearbeitet, es schneller zu machen, und die Verwendung der JavaConfig-Bibliothek sollte die Dinge beschleunigen.

Benutzerfreundlichkeit

Pico - Einfach zu konfigurieren. Pico kann einige Autodrahtentscheidungen für Sie treffen. Nicht klar, wie es auf sehr große Projekte skaliert.

Guice - Einfach zu konfigurieren, fügen Sie einfach Anmerkungen hinzu und erben von AbstractModule, um die Dinge miteinander zu verbinden. Skaliert gut auf große Projekte, da die Konfiguration auf ein Minimum beschränkt ist.

Spring - Relativ einfach zu konfigurieren, aber die meisten Beispiele verwenden Spring XML als Konfigurationsmethode. Spring XML-Dateien können im Laufe der Zeit sehr groß und komplex werden und das Laden einige Zeit in Anspruch nehmen. Verwenden Sie eine Mischung aus Feder und handgekurbelter Abhängigkeitsinjektion, um dies zu überwinden.

Gemeinschaftsgröße

Pico - Klein

Guice - Mittel

Frühling - groß

Erfahrung

Pico - Ich habe nicht viel Erfahrung mit Pico, aber es ist kein weit verbreitetes Framework, daher wird es schwieriger sein, Ressourcen zu finden.

Guice - Guice ist ein beliebtes Framework und sein Fokus auf Geschwindigkeit ist willkommen, wenn Sie ein großes Projekt haben, das Sie in der Entwicklung häufig neu starten. Ich habe Bedenken hinsichtlich der Verteilung der Konfiguration, dh es ist nicht leicht zu erkennen, wie unsere gesamte Anwendung zusammengesetzt ist. In dieser Hinsicht ist es ein bisschen wie AOP.

Frühling - Frühling ist normalerweise meine Standardwahl. Das XML kann jedoch umständlich und die daraus resultierende Verlangsamung ärgerlich werden. Am Ende verwende ich oft eine Kombination aus handgefertigter Abhängigkeitsinjektion und Feder. Wenn Sie tatsächlich eine XML-basierte Konfiguration benötigen, ist Spring XML recht gut. Spring hat auch große Anstrengungen unternommen, um andere Frameworks für Dependency Injection benutzerfreundlicher zu machen. Dies kann nützlich sein, da sie dabei häufig bewährte Methoden verwenden (JMS, ORM, OXM, MVC usw.).

Verweise

• Pico
• Guice
• Frühling
• Spring / Guice / Pico Vergleich
• Ein weiterer Leistungsvergleich zwischen Spring und Guice

Die Antwort von jamie.mccrindle ist eigentlich ziemlich gut, aber ich bin verwirrt, warum Spring die Standardauswahl ist, wenn ziemlich klar ist, dass überlegene Alternativen (sowohl Pico als auch Guice) verfügbar sind. Die Popularität von IMO Spring hat ihren Höhepunkt erreicht und lebt derzeit vom generierten Hype (zusammen mit all den anderen "Ich auch" Spring-Subprojekten, die den Spring-Zug fahren wollen).

Spring einziger wirklicher Vorteil ist Gemeindegröße (und ehrlich gesagt, aufgrund der Größe und Komplexität, es gebraucht wird ), aber Pico und Guice nicht benötigen eine große Gemeinschaft , weil ihre Lösung viel sauberer ist, besser organisiert und eleganter. Pico scheint flexibler zu sein als Guice (Sie können Anmerkungen in Pico verwenden oder nicht - es ist äußerst effizient). (Bearbeiten: Bedeutet, dass es extrem flexibel ist, nicht, dass es nicht auch effizient ist.)

Picos winzige Größe und das Fehlen von Abhängigkeiten sind ein großer Gewinn, der nicht zu unterschätzen ist. Wie viele Megabyte müssen Sie herunterladen, um Spring jetzt nutzen zu können? Es ist ein Durcheinander riesiger JAR-Dateien mit all ihren Abhängigkeiten. Intuitiv zu denken, sollte eine solch effiziente und "kleine" Lösung skalieren und eine bessere Leistung erbringen als etwas wie Spring. Wird das Aufblähen des Frühlings die Skalierung wirklich verbessern? Ist das eine bizarre Welt? Ich würde nicht davon ausgehen, dass Spring "skalierbarer" ist, bis dies bewiesen (und erklärt) ist.

Manchmal funktioniert es wirklich, etwas Gutes zu kreieren (Pico / Guice) und dann die HÄNDE davon fernzuhalten, anstatt Funktionen zum Aufblähen und Spülen mit endlosen neuen Versionen hinzuzufügen ...

HINWEIS: Dies ist eher ein Kommentar als eine Antwort

PicoContainer ist großartig. Ich würde wieder darauf zurückgreifen, wenn sie nur ihre Websites reparieren würden. Es ist jetzt wirklich verwirrend:

• http://picocontainer.com ist die neueste, aber viele Seiten haben Formatierungsprobleme und einige Seiten funktionieren überhaupt nicht. Es sieht so aus, als ob die Seiten automatisch aus dem älteren Inhalt konvertiert wurden.
• http://picocontainer.codehaus.org/ Was in Version 2.10.2 eingefroren zu sein scheint - Es wäre wirklich schön, wenn auf den Seiten so etwas wie "Hey, Sie sehen sich eine alte Website an!"
• http://docs.codehaus.org/display/PICO/Home - Ein Zusammenfluss-Wiki, das v 1.x dokumentiert, aber nirgendwo auf den Seiten steht!

Ich verwende jetzt Guice 2.x, obwohl es größer ist und weniger Funktionen hat. Es war einfach viel einfacher, die Dokumentation zu finden, und die Benutzergruppe ist sehr aktiv. Wenn jedoch die Richtung von Guice 3 ein Hinweis ist, sieht es so aus, als würde Guice langsam aufblähen, so wie es der Frühling in den frühen Tagen getan hat.

Update: Ich habe einen Kommentar zu den Pico Container-Leuten gepostet und sie haben einige Verbesserungen an der Website vorgenommen. Viel besser jetzt!

Es ist eine alte Frage, aber heute können Sie Dolch ( https://github.com/square/dagger ) in Ihrem Android App-Projekt berücksichtigen . Dagger generiert Code zur Kompilierungszeit. So erhalten Sie eine kürzere Startzeit und weniger Speicherbedarf bei der Ausführung.

Wenn Sie nach einem minimalistischen DI-Container suchen, können Sie sich Feather ansehen . Nur Vanilla JSR-330 DI-Funktionalität, aber recht gut in Bezug auf Platzbedarf (16 KB, keine Abhängigkeiten) und Leistung. Funktioniert auf Android.

Obwohl ich PicoContainer wegen seiner Einfachheit und des Mangels an Abhängigkeiten mag. Ich würde empfehlen, stattdessen CDI zu verwenden, da es Teil des Java EE-Standards ist, sodass Sie keine Lieferantenbindung haben.

In Bezug auf die Eindringlichkeit besteht das Hauptproblem in der Anforderung eines Containers und der Verwendung einer relativ leeren META-INF / beans.xml-Datei (erforderlich, um anzuzeigen, dass das Jar CDI verwendet) und in der Verwendung von Anmerkungen (obwohl diese Standard sind) )

Der leichtgewichtige CDI-Container, den ich für meine eigenen Projekte verwende, ist Apache Open Web Beans. Es hat jedoch eine Weile gedauert, um herauszufinden, wie man eine einfache App erstellt (im Gegensatz zu Pico), die so aussieht.

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