Google Guice contre PicoContainer for Dependency Injection

Question

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. Facilité d'utilisation - faut-il 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 ;) 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.

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

Answer 1

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:

Attelage pour 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 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 de 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

L'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 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

• Pico
• Guice
• Printemps
• Printemps / Guice / Pico comparaison
• Un autre Printemps / Guice comparaison des performances

Answer 2

La réponse avancée 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 train en marche).

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 n'avez pas besoin d' 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 fonctionne vraiment...

Answer 3

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 - Ce 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!

Answer 4

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

Answer 5

Même si j'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 d'ingérence, 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();
}