Google Guice vs PicoContainer pour l'Injection de Dépendances

Mon équipe de recherche de l'injection de dépendance et des cadres est en train de décider entre l'utilisation de Google Guice et PicoContainer.

Nous sommes à la recherche pour plusieurs choses dans notre cadre:

  1. Une petite empreinte de code - Ce que je veux dire par une petite empreinte de code c'est que nous ne voulons pas de l'injection de dépendances code de la litière partout dans notre base de code. Si nous avons besoin de refactoriser en bas de la route, nous voulons qu'il soit aussi facile que possible.
  2. Performance - Combien de frais généraux n'chaque cadre lors de la création et de l'injection des objets?
  3. La facilité d'utilisation Est là une grande courbe d'apprentissage? Faut-il écrire des tas de code pour obtenir quelque chose de simple travail? Nous voulons avoir que peu de configuration possible.
  4. La taille de la collectivité - les Grandes communautés signifie généralement qu'un projet continuera à être maintenue. Nous ne voulons pas l'utilisation d'un cadre et de corriger nos propres bugs 😉 Aussi toutes les questions que nous avons, le long de la voie est (je l'espère) être répondu par la cadre de son développeur/utilisateur de la communauté .

Comparaisons de la deux cadres contre les critères de la liste serait grandement apprécié. Toutes les expériences personnelles qui permettent de comparer les deux serait également très utile.

Disclaimer: je suis assez nouveau à l'injection de dépendance, donc excusez mon noob-ness si je pose une question qui n'est pas pertinent à cette discussion.

InformationsquelleAutor austen | 2010-01-08
  1. 113

    Vous voudrez peut-être inclure le Printemps dans votre liste d'Injection de Dépendance des cadres que vous envisagez. Voici quelques réponses à vos questions:

    De couplage sur le cadre

    Pico - Pico tend à décourager l'injection par mutateur mais autre que cela, les classes n'ont pas besoin de savoir à propos de Pico. C'est seulement le câblage qui a besoin de savoir (vrai pour tous les DI cadres).

    Guice - Guice prend désormais en charge la norme La JSR 330 annotations, de sorte que vous n'avez pas besoin de Guice des annotations spécifiques dans votre code plus. Le printemps prend également en charge ces annotations standard. L'argument que le Guice gars, c'est que sans un Guice processeur d'annotation en cours d'exécution, ceux-ci ne devraient pas avoir un impact si vous décidez d'utiliser un autre cadre.

    Printemps - Printemps vise à vous permettre d'éviter toute mention du framework Spring dans votre code. Parce qu'ils ont beaucoup d'autres helpers /utilitaires etc. la tentation est très forte de dépendre de Printemps code.

    Performance

    Pico - je ne suis pas trop familier avec les caractéristiques de vitesse Pico

    Guice - Guice a été conçu pour être rapide et la comparaison mentionné dans la référence de certains numéros. Certes, si la vitesse est une considération primordiale, soit à l'aide de Guice ou le filage à la main doit être considéré comme

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

    La facilité d'utilisation

    Pico - Simple à configurer. Pico pouvez faire quelques autowire décisions pour vous. Pas évident de savoir comment elle s'adapte à de très grands projets.

    Guice - Simple à configurer, il suffit d'ajouter des annotations et hériter de AbstractModule de lier les choses ensemble. Échelles pour les grands projets que la configuration est réduite à un minimum.

    Printemps - Relativement facile à configurer, mais la plupart des exemples d'utilisation de Printemps XML comme la méthode de configuration. Le printemps des fichiers XML peuvent devenir très volumineux et complexes au fil du temps et de prendre du temps à charger. Envisager l'utilisation d'une combinaison de Printemps et de la main une manivelle d'Injection de Dépendance pour remédier à cela.

    La Taille De La Collectivité

    Pico - Petit

    Guice - Moyen

    Printemps - Grand

    Expérience

    Pico - je n'ai pas eu beaucoup d'expérience avec Pico, mais il n'est pas largement utilisée cadre de sorte qu'il sera plus difficile de trouver des ressources.

    Guice - Guice est un cadre populaire et son accent sur la vitesse est la bienvenue quand vous avez un grand projet que vous êtes en redémarrant beaucoup dans le développement. J'ai une préoccupation au sujet de la nature distribuée de la configuration c'est à dire qu'il n'est pas facile de voir comment notre application est mis en place. C'est un peu comme AOP à cet égard.

    Printemps - le Printemps est généralement mon choix par défaut. Cela dit, le XML peut devenir lourd et le ralentissement gênant. Je finissent souvent à l'aide d'une combinaison de fabriqué à la main de l'Injection de Dépendance et de Printemps. Lorsque vous avez réellement besoin de XML en fonction de la configuration, le Printemps XML est assez bonne. Le printemps a également mis beaucoup d'effort dans d'autres cadres plus de l'Injection de Dépendances friendly qui peuvent être utiles parce qu'ils utilisent souvent les meilleures pratiques en faisant de la sorte (JMS, ORM, OXM, MVC, etc.).

    Références

    • 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 de poids que Guice. Aussi, en regardant si le PicoContainer doc, il semble aussi être plus simple à utiliser. Il recherche des dépendances dans les constructeurs lui-même et que vous n'avez pas besoin de spécifier le constructeur à utiliser. Il utilise juste un correspondant.
    • Yep, je suis de big sur PicoContainer maintenant moi-même. C'est juste un "keep it simple", pas encore de solution, je ne peux pas m'empêcher de regarder au Printemps de ballonnement et obsolètes de nos jours. Guice est aussi sympa (et a un bon allié w/Google), mais je crois Pico a également plus de fonctionnalités et de flexibilité, d'être âgé. Il est bon de voir de belles alternatives à de mauvaises xml de configuration!
    • En référence à la "pas utilisé de" description de Pico ci-dessus, c'est vrai que c'est pas aussi populaire que les autres, mais en considérant qu'il est plus petit/plus simple que les autres solutions, vous êtes beaucoup moins susceptibles de courir dans des problèmes inhabituels. Si vous le faites, il ya une belle et très réactif liste de diffusion. Aussi Pico est non-invasive (sauf si vous décidez d'utiliser des annotations, c'est une option), vous n'avez pas besoin d'annotation comme Guice, ce qui signifie moins de travail de câblage de l'injection de code. (ouais je suis partial, mais Pico est juste que cool) Guice est certainement une bonne DI outil (mieux que le Printemps de l'OMI), si.
    • Juste mon avis: je suis passé de Pico à Guice, parce que je sentais Guice a été plus facile à utiliser. L'ajout d'annotations à des composants augmente les dépendances, mais ce n'était pas un facteur important pour nous en tant que Guice est essentiellement deux pots. Sur le côté positif, ayant @Inject sur les constructeurs rend les autres développeurs sont conscients que l'objet est un composant. Cela dit, je ne pense pas qu'il y est quelque chose de mal avec Pico. Je viens de trouver Guice un peu plus facile à utiliser.
    • J'utilise pico dans un certain nombre de très grandes et lourdes-utilisation) des projets (des centaines de types de composants définis dans chaque conteneur), et la plupart de tous ses diverses fonctions, et ne pouvais pas être plus heureux avec elle.
    • Je viens de faire un simple test de performance avec Guice/Printemps/PicoContainer - Guice et PicoContainer sont assez semblables. Dans certains cas, Guice a été un peu plus rapide. Le printemps a été très lente dans tous les cas.

    InformationsquelleAutor Jamie McCrindle
  2. 25

    La réponse mis en place par jamie.mccrindle est en fait assez bonne, mais je suis confus pourquoi le Printemps est le choix par défaut quand il est assez clair qu'supérieure alternatives (à la fois Pico et Guice) sont disponibles. OMI Printemps popularité a atteint son pic et maintenant il est vivant actuellement hors de l'généré hype (ainsi que tous les autres "moi aussi" Printemps des sous-projets qui cherchent à monter le Ressort mouvement).

    Printemps, le seul véritable avantage est la taille de la collectivité (et franchement, en raison de la taille et de la complexité, il est nécessaire), mais Pico et Guice ne pas besoin une énorme communauté, parce que leur solution est beaucoup plus propre, plus organisée et plus élégante. Pico semble plus souple que Guice (vous pouvez utiliser des annotations dans les Pico, ou pas--c'est très efficace).
    (Edit: voulu dire, c'est extrêmement flexible, non pas qu'il n'est pas aussi efficace.)

    Pico de petite taille et le manque de dépendances est une grande victoire qui ne doit pas être sous-estimée. Combien de mégas, vous devez télécharger pour utiliser le Printemps maintenant? C'est une encombrants gâchis énorme de fichiers jar, avec toutes ses dépendances. Intuitivement penser, une telle efficacité et les "petits" la solution de l'échelle et mieux que quelque chose comme le Printemps. C'est le Printemps de la météorisation vraiment l'intention de le faire à l'échelle de mieux? Est-ce bizarro world? Je ne voudrais pas faire de suppositions que le Printemps est "scalable" tant que ce n'est pas prouvé (et expliqué).

    Parfois la création de quelque chose de bon (Pico/Guice) et ensuite garder vos MAINS loin de lui au lieu de l'ajout de la météorisation et l'évier de la cuisine de fonctionnalités avec d'innombrables nouvelles versions ne fonctionne vraiment pas sur...

    • Soin de dire pourquoi Pico et Guice sont de qualité supérieure pour le Printemps?
    • J'ai pensé que je n'ai - pour l'essentiel, ils ne DI tout aussi bien, ils sont plus simple/petit/plus propre, et pas ou peu de dépendances. Cela ne veut pas dire que le Printemps jamais de bon sens (je suis sûr qu'il y a des cas), tout ce que je veux dire c'est que le plus simple est mieux si vos exigences sont respectées. Et pour un très grand nombre de projets, petit support libs sont tous vous avez besoin.
    InformationsquelleAutor Manius
  3. 11

    REMARQUE: Ce n'est plus un commentaire/coup de gueule qu'une réponse

    PicoContainer est grande. Je voudrais revenir si on venait de fixer leurs sites web. C'est vraiment confus maintenant:

    • http://picocontainer.com qui est la plus récente, mais le nombre de pages qui ont des problèmes de mise et quelques pages ne fonctionnent pas du tout. On dirait que les pages ont été automatiquement converti à partir du contenu plus ancien.
    • http://picocontainer.codehaus.org/ Qui semble figée dans le temps à la version 2.10.2 - Il serait vraiment sympa si les pages a dit quelque chose comme "hé, vous êtes en train de regarder un vieux site web!"
    • http://docs.codehaus.org/display/PICO/Home - Une confluence que les documents v 1.x, mais cela ne veut pas dire que n'importe où sur les pages!

    Je suis l'aide de Guice 2.x maintenant, même si il est plus grand, et il a moins de fonctionnalités. Il était juste beaucoup plus facile de trouver de la documentation, et c'est l'utilisateur d'un groupe très actif. Toutefois, si la direction de Guice 3 est une indication, il ressemble à Guice commence à gonfler, tout comme le Printemps n'chemin du retour dans les premiers jours.

    Mise à jour: j'ai posté un commentaire pour le Pico Conteneur des gens et qu'ils ont fait quelques améliorations sur le site web. Beaucoup mieux maintenant!

    • Mais codehaus site encore gelé et pas d'info à propos de n'importe quel mouvement. J'ai pensé Pico est mort 😉
    • Si le site n'est pas à jour avec le code, il peut être une indication que le projet est tombé au-dessous de la masse critique.
    • Oui. Malheureusement, je pense que Pico a été remplacée par Guice et CDI.
    • Le 8 Mars 2013, le picocontainer.org site web semble être occupé par un domaine de squatters. picocontainer.com semble être la forme canonique d'un site web.
    InformationsquelleAutor Joshua Davis
  4. 2

    C'est une vieille question, mais aujourd'hui, vous pouvez envisager de Poignard (https://github.com/square/dagger) dans votre Application Android du projet.
    La dague n'génération de code sur le temps de 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.

    • J'aime Poignard, mais il semble qu'il n'y a pas un plugin Gradle dans le public repos pour les non-Android projets encore (c'est à dire un plugin Gradle pour "régulier" des projets java). J'avais l'envisager pour les projets Java, si il y avait un plugin dans le public repos.
    InformationsquelleAutor A.C.Andreani
  5. 1

    Si vous êtes après un minimaliste DI conteneur, vous pouvez consulter Plume. Vanille JSR 330 DI fonctionnalité seulement, mais assez bon en termes d'empreinte (16K, pas de dépendances) et de la performance. Fonctionne sur android.

    • Hey, la Plume est génial! Je l'ai utilisé pour mettre en œuvre une DI plugin pour ActFramework. J'ai fait quelques mises à jour, par exemple, appeler automatiquement injectFields si nécessaire, et une assistance à l'injection à l'écoute, laissez-moi savoir si vous voulez m'envoyer une demande d'extraction
    • Je vois que vous avez changé de Genie. Pourriez-vous s'il vous plaît partager vos expériences avec l'utilisation de la Plume?
    • La plume est très léger et très facile à utiliser en plus de la DI de cas d'utilisation. Cependant depuis que je suis en train de travailler sur un fullstack framework MVC, j'ai besoin d'une solution qui mettent en œuvre complète JSR330 spec. C'est pourquoi j'ai déménagé Genie
    • Je vous remercie de votre post de l'explication pour obtenir une meilleure compréhension.
    InformationsquelleAutor Cellux
  6. 0

    Bien que je n'aime PicoContainer pour sa simplicité et c'est le manque de dépendances. Je recommande l'utilisation de CDI à la place car il fait partie de Java EE standard si vous n'avez pas de vendor lock-in.

    En termes de degré d'intrusion, c'est la principale problème est l'exigence d'un conteneur et l'utilisation de relativement vide META-INF/beans.xml fichier (ce qui est nécessaire pour indiquer que le pot est à l'aide de CDI) et de l'utilisation des annotations (même si elles sont standard)

    Le léger conteneur CDI-je utiliser pour mes propres projets est Apache Open Web Haricots. Mais il a 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();
}
    • Si vous restez avec JSR 330 dans votre bibliothèque de code, vous pouvez garder le contenant le code spécifique à un minimum.
    • Vous avez encore besoin de conteneur de code spécifique dans votre test automatisé. Bien que cela ne signifie pas que vous auriez conteneur spécifique de code dans votre code (et vous ne devriez pas, de toute façon, sauf si vous envisagez de lancer votre propre "principal" qui, en une seule application que j'ai écrit pour moi-même je l'ai fait.
    InformationsquelleAutor Archimedes Trajano