Google Guice contre PicoContainer pour l'injection de dépendances

Mon équipe recherche des frameworks d'injection de dépendances et essaie de décider entre l'utilisation de Google-Guice et PicoContainer.

Nous recherchons plusieurs choses dans notre cadre:

1. Une petite empreinte de code - Ce que j'entends par une petite empreinte de code, c'est que nous ne voulons pas avoir de litière de code d'injection de dépendances partout dans notre base de code. Si nous devons refactoriser sur la route, nous voulons que ce soit aussi simple que possible.
2. Performances - Quelle est la surcharge de chaque framework lors de la création et de l'injection d'objets?
3. Facilité d'utilisation - Y a-t-il une grande courbe d'apprentissage? Devons-nous écrire des tas de code pour faire fonctionner quelque chose de simple? Nous voulons avoir le moins de configuration possible.
4. Taille de la communauté - Des communautés plus grandes signifient généralement qu'un projet continuera d'être maintenu. Nous ne voulons pas utiliser de framework et devons corriger nos propres bogues;) Aussi toutes les questions que nous avons en cours de route peuvent (espérons-le) être répondues par la communauté des développeurs / utilisateurs du framework.

Des comparaisons des deux cadres avec les critères énumérés seraient grandement appréciées. Toute expérience personnelle permettant de comparer les deux serait également extrêmement utile.

Avertissement: je suis assez nouveau dans l'injection de dépendances, alors excusez-moi si je posais une question qui n'est pas pertinente pour cette discussion.

Vous souhaiterez peut-être inclure Spring dans votre liste de frameworks d'injection de dépendances que vous envisagez. Voici quelques réponses à vos questions:

Accouplement au cadre

Pico - Pico a tendance à décourager l'injection de setter, mais à part cela, vos cours n'ont pas besoin de connaître Pico. Seul le câblage doit être connu (vrai pour tous les frameworks DI).

Guice - Guice prend désormais en charge les annotations standard JSR 330 , vous n'avez donc plus besoin d'annotations spécifiques à Guice dans votre code. Spring prend également en charge ces annotations standard. L'argument que les gars de Guice utilisent est que sans un processeur d'annotation Guice en cours d'exécution, cela ne devrait pas avoir d'impact si vous décidez d'utiliser un autre framework.

Spring - Spring a pour objectif de vous permettre d'éviter toute mention du framework Spring dans votre code. Parce qu'ils ont beaucoup d'autres aides / utilitaires, etc., la tentation est assez forte de dépendre du code Spring, cependant.

Performance

Pico - Je ne connais pas trop les caractéristiques de vitesse du Pico

Guice - Guice a été conçu pour être rapide et la comparaison mentionnée dans la référence comporte quelques chiffres. Certes, si la vitesse est une considération primordiale, soit l'utilisation de Guice, soit le câblage manuel doit être envisagée

Printemps - Le printemps peut être lent. Il y a eu du travail pour le rendre plus rapide et l'utilisation de la bibliothèque JavaConfig devrait accélérer les choses.

Facilité d'utilisation

Pico - Simple à configurer. Pico peut prendre des décisions en matière de câblage automatique pour vous. On ne sait pas comment il s’adapte à de très grands projets.

Guice - Simple à configurer, il vous suffit d'ajouter des annotations et d'hériter de AbstractModule pour lier les choses ensemble. S'adapte bien aux grands projets car la configuration est réduite au minimum.

Spring - Relativement facile à configurer, mais la plupart des exemples utilisent Spring XML comme méthode de configuration. Les fichiers XML Spring peuvent devenir très volumineux et complexes au fil du temps et prendre du temps à se charger. Pensez à utiliser un mélange d'injection de dépendance à ressort et à manivelle pour surmonter ce problème.

Taille de la communauté

Pico - Petit

Guice - Moyen

Printemps - Grand

Expérience

Pico - Je n'ai pas beaucoup d'expérience avec Pico mais ce n'est pas un cadre largement utilisé, il sera donc plus difficile de trouver des ressources.

Guice - Guice est un framework populaire et son accent sur la vitesse est le bienvenu lorsque vous avez un grand projet que vous redémarrez beaucoup en développement. Je suis préoccupé par la nature distribuée de la configuration, c'est-à-dire qu'il n'est pas facile de voir comment toute notre application est mise en place. C'est un peu comme AOP à cet égard.

Spring - Spring est généralement mon choix par défaut. Cela dit, le XML peut devenir encombrant et le ralentissement qui en résulte ennuyeux. Je finis souvent par utiliser une combinaison d'injection de dépendance et de ressort fabriqués à la main. Lorsque vous avez réellement besoin d'une configuration basée sur XML, Spring XML est assez bon. Spring a également déployé beaucoup d'efforts pour rendre d'autres frameworks plus conviviaux pour l'injection de dépendances, ce qui peut être utile car ils utilisent souvent les meilleures pratiques pour le faire (JMS, ORM, OXM, MVC, etc.).

Références

• Pico
• Guice
• Printemps
• Comparaison Spring / Guice / Pico
• Une autre comparaison des performances Spring / Guice

La réponse proposée par jamie.mccrindle est en fait plutôt bonne, mais je ne comprends pas pourquoi Spring est le choix par défaut alors qu'il est assez clair que des alternatives supérieures (Pico et Guice) sont disponibles. La popularité de IMO Spring a atteint son apogée et maintenant il vit actuellement du battage médiatique généré (avec tous les autres sous-projets de printemps «moi aussi» qui cherchent à suivre le train en marche Spring).

Le seul avantage réel de Spring est la taille de la communauté (et franchement, en raison de la taille et de la complexité, c'est nécessaire), mais Pico et Guice n'ont pas besoin d' une énorme communauté car leur solution est beaucoup plus propre, plus organisée et plus élégante. Pico semble plus flexible que Guice (vous pouvez utiliser des annotations dans Pico, ou pas - c'est extrêmement efficace). (Edit: Cela veut dire que c'est extrêmement flexible, non pas que ce n'est pas aussi efficace.)

La petite taille de Pico et le manque de dépendances est une victoire MAJEURE qui ne devrait pas être sous-estimée. Combien de Mo devez-vous télécharger pour utiliser Spring maintenant? C'est un kludgy-mess d'énormes fichiers jar, avec toutes ses dépendances. En pensant intuitivement, une solution aussi efficace et «petite» devrait évoluer et fonctionner mieux que quelque chose comme Spring. Le gonflement de Spring va-t-il vraiment l'améliorer? Est-ce ce monde bizarro? Je ne ferais pas l'hypothèse que Spring est "plus évolutif" jusqu'à ce que cela soit prouvé (et expliqué).

Parfois, créer quelque chose de bien (Pico / Guice) et ensuite garder vos MAINS LIBRES au lieu d'ajouter des fonctionnalités de ballonnement et d'évier de cuisine avec de nouvelles versions sans fin fonctionne vraiment ...

REMARQUE: Ceci est plus un commentaire / diatribe qu'une réponse

PicoContainer est génial. Je reviendrais dessus s'ils réparaient simplement leurs sites Web. C'est vraiment déroutant maintenant:

• http://picocontainer.com qui est le plus récent, mais de nombreuses pages ont des problèmes de formatage et quelques pages ne fonctionnent pas du tout. Il semble que les pages aient été automatiquement converties à partir du contenu plus ancien.
• http://picocontainer.codehaus.org/ Ce qui semble figé dans le temps à la version 2.10.2 - Ce serait vraiment bien si les pages disaient quelque chose comme "hé, vous regardez un vieux site Web!"
• http://docs.codehaus.org/display/PICO/Home - Un wiki de confluence qui documente la v 1.x, mais cela ne dit rien sur les pages!

J'utilise Guice 2.x maintenant, même s'il est plus grand et qu'il a moins de fonctionnalités. Il était juste beaucoup plus facile de trouver la documentation, et son groupe d'utilisateurs est très actif. Cependant, si la direction de Guice 3 est une indication, il semble que Guice commence à gonfler, tout comme Spring l'a fait dans les premiers jours.

Mise à jour: J'ai posté un commentaire aux gens de Pico Container et ils ont apporté quelques améliorations au site Web. Bien mieux maintenant!

C'est une vieille question, mais aujourd'hui, vous pouvez envisager Dagger ( https://github.com/square/dagger ) dans votre projet d'application Android. Dagger génère du code au moment de la compilation. Ainsi, vous obtenez un temps de démarrage plus court et moins d'utilisation de la mémoire sur le temps d'exécution.

Si vous recherchez un conteneur DI minimaliste, vous pouvez consulter Feather . Fonctionnalité Vanilla JSR-330 DI uniquement, mais assez bonne en termes d'encombrement (16K, pas de dépendances) et de performances. Fonctionne sur Android.

Bien que j'aime PicoContainer pour sa simplicité et son manque de dépendances. Je recommanderais plutôt d'utiliser CDI car il fait partie de la norme Java EE, vous n'avez donc pas de verrouillage du fournisseur.

En termes d'intrusion, son principal problème est l'exigence d'un conteneur et l'utilisation d'un fichier META-INF / beans.xml relativement vide (nécessaire pour indiquer que le jar utilise CDI) et l'utilisation d'annotations (bien qu'elles soient standard )

Le conteneur CDI léger que j'utilise pour mes propres projets est Apache Open Web Beans. Bien qu'il ait fallu un certain temps pour comprendre comment créer une application simple (contrairement à Pico) qui ressemble à ceci.

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