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

100

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.

Austen
la source
Mise à jour: vous pouvez également envisager CDI 2.0 - Injection de contextes et de dépendances pour Java . Standardisé dans JSR 365 à partir de 2017-04.
Basil Bourque

Réponses:

115

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

Jamie McCrindle
la source
1
Ce que j'ai appris (de quelqu'un d'autre plutôt que de l'utiliser moi-même), c'est que PicoContainer est plus léger que Guice. En outre, en regardant la documentation PicoContainer, il semble également être plus simple à utiliser. Il recherchera les dépendances dans les constructeurs lui-même et vous n'avez pas besoin de spécifier le constructeur à utiliser. Il utilise juste un correspondant.
Kissaki
2
Oui, je suis moi-même grand sur PicoContainer maintenant. C'est juste une telle solution "Keep it simple", mais qui fonctionne, je ne peux pas m'empêcher de regarder Spring comme gonflé et dépassé de nos jours. Guice est également gentil (et a un bon soutien avec Google), mais je pense que Pico a également plus de fonctionnalités / flexibilité, étant plus âgé. Il est bon de voir de belles alternatives à la mauvaise configuration xml!
Manius
En référence à la description «peu utilisée» de Pico ci-dessus, il est vrai qu'il n'est pas aussi populaire que les autres, mais étant donné qu'il est plus petit / plus simple que les autres solutions, vous êtes beaucoup moins susceptible de rencontrer des problèmes inhabituels. Si vous le faites, il existe une liste de diffusion agréable et très réactive. De plus, Pico est non invasif (à moins que vous ne décidiez d'utiliser des annotations, c'est une option), vous n'avez pas besoin d'annotations comme Guice, ce qui signifie moins de travail pour le câblage du code d'injection. (Ouais, je suis partial, mais Pico est juste que cool) Guice est certainement un bon outil de DI (meilleur que Spring IMO), cependant.
Manius
1
J'utilise pico dans un certain nombre de projets très volumineux (et à usage intensif) (des centaines de types de composants définis dans chaque conteneur), et j'ai utilisé la plupart de ses différentes fonctionnalités, et je ne pourrais pas être plus satisfait.
jhouse
2
Je viens de faire un simple test de performance avec Guice / Spring / PicoContainer - Guice et PicoContainer sont assez similaires. Dans certains cas, Guice était un peu plus rapide. Le printemps a été très lent dans tous les cas.
Joshua Davis
25

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 ...

Manius
la source
1
Voulez-vous dire pourquoi Pico et Guice sont supérieurs à Spring?
Thorbjørn Ravn Andersen
4
Je pensais que je l'avais fait - en gros, ils font aussi bien la DI, ils sont plus simples / plus petits / plus propres et pas ou peu de dépendances. Cela ne veut pas dire que Spring n'a jamais de sens (je suis sûr qu'il y a des cas), tout ce que je dis, c'est que plus simple est mieux si vos exigences sont satisfaites. Et pour un très grand nombre de projets, de petites bibliothèques de support sont tout ce dont vous avez besoin.
Manius
12

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!

Joshua Davis
la source
Mais le site Web de codehaus est toujours gelé et aucune information sur un déménagement. Je pensais que Pico était mort;)
Vladislav Rastrusny
1
Si le site Web n'est pas à jour avec le code, cela peut indiquer que le projet est tombé en dessous de la masse critique.
Thorbjørn Ravn Andersen
@ ThorbjørnRavnAndersen Oui. Malheureusement, je pense que Pico a été remplacé par Guice et CDI.
Joshua Davis
5
Au 8 mars 2013, le site picocontainer.org semble être occupé par un squatter de domaine. picocontainer.com semble être le site Web canonique maintenant.
dOxxx
2

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.

ACAndreani
la source
J'aime Dagger, mais il semble qu'il n'y ait pas encore de plugin Gradle dans les dépôts publics pour les projets non Android (c'est-à-dire un plugin Gradle pour les projets java «normaux»). Je l'envisagerais pour les projets Java s'il y avait un plugin dans les dépôts publics.
Joshua Davis
2

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.

Cellux
la source
Hé, Feather est géniale! Je l' ai utilisé pour mettre en œuvre un plugin DI pour ActFramework . J'ai fait quelques mises à jour, par exemple, appeler automatiquement injectFields si nécessaire, et prendre en charge l'auditeur d'injection, faites-moi savoir si vous voulez que je renvoie une demande de tirage
Gelin Luo
@green Je vois que vous avez déménagé chez Genie. Pourriez-vous s'il vous plaît partager vos expériences d'utilisation de Feather?
beerBear
1
@beerBear Feather est très léger et très facile à utiliser dans la plupart des cas d'utilisation de DI. Cependant, comme je travaille sur un framework MVC fullstack, j'ai besoin d'une solution qui implémente la spécification JSR330 complète. C'est pourquoi j'ai déménagé à Genie
Gelin Luo
@green J'apprécie votre message d'explication pour avoir une meilleure compréhension.
beerBear
0

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();
}
Archimède Trajano
la source
2
Si vous vous en tenez à JSR-330 dans le code de votre bibliothèque, vous pouvez réduire au minimum le code spécifique au conteneur.
Thorbjørn Ravn Andersen
Vous avez toujours besoin d'un code spécifique au conteneur dans vos tests automatisés. Bien que cela ne signifie pas que vous auriez du code spécifique au conteneur dans votre code réel (et vous ne devriez pas de toute façon à moins que vous ne prévoyiez d'exécuter votre propre "main", ce que j'ai fait dans une application que j'ai écrite pour moi-même.
Archimedes Trajano