Google Guice contre PicoContainer pour l'injection de dépendance
Mon équipe recherche des frameworks d'injection de dépendances et essaie de décider entre l'utilisation de Google-Guice et de PicoContainer.
Nous recherchons plusieurs éléments dans notre cadre:
- Une petite empreinte de code - Ce que je veux dire par une petite empreinte de code est que nous ne voulons pas avoir de litière de code d'injection de dépendance partout dans notre base de code. Si nous devons refactoriser la route, nous voulons que ce soit aussi simple que possible.
- Performances - Quelle est la surcharge de chaque infrastructure lors de la création et de l'injection d'objets?
- Facilité d'utilisation - Y a-t-il une grande courbe d'apprentissage? Faut-il écrire des monticules de code pour faire fonctionner quelque chose de simple? Nous voulons avoir le moins de configuration possible.
- 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 un framework et devons corriger nos propres bugs;) De plus, 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 qui aiderait à comparer les deux serait également extrêmement utile.
Avis de non-responsabilité: Je suis relativement nouveau dans l'injection de dépendances, alors excusez-moi si je pose une question qui n'est pas pertinente pour cette discussion.
Vous voudrez peut-être inclure Spring dans votre liste de cadres d'injection de dépendance que vous envisagez. Voici quelques réponses à vos questions:
Couplage au cadre
Pico - Pico a tendance à décourager l'injection de setter mais à part ça, vos classes n'ont pas besoin de connaître Pico. Ce n'est que le câblage qui doit être connu (vrai pour tous les cadres DI).
Guice - Guice prend désormais en charge les annotations standard JSR 3 , 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, ceux-ci ne devraient pas avoir d'impact si vous décidez d'utiliser un framework différent.
Spring - Spring a pour but 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 de Pico
Guice - Guice a été conçu pour être rapide et la comparaison mentionnée dans la référence a quelques chiffres. Certes, si la vitesse est une considération primordiale, soit en utilisant Guice, soit en câblant à la main,
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 de câblage automatique pour vous. Pas clair comment il évolue vers 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 à charger. Envisagez d'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
Ressort - Large
Expérience
Pico - Je n'ai pas beaucoup d'expérience avec Pico mais ce n'est pas un framework largement utilisé donc il sera plus difficile de trouver des ressources.
Guice - Guice est un framework populaire et l'accent mis sur la vitesse est le bienvenu lorsque vous avez un grand projet que vous redémarrez beaucoup en cours de 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 l'ensemble de notre application est composée. 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 lourd et le ralentissement qui en résulte ennuyeux. Je finis souvent par utiliser une combinaison d'injection de dépendance fabriquée à la main et de ressort. 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 (JMS, ORM, OXM, MVC, etc.).
Les références
La réponse proposée par jamie.mccrindle est en fait assez bonne, mais je ne comprends pas pourquoi Spring est le choix par défaut quand il est assez clair que des alternatives supérieures (à la fois Pico et Guice) sont disponibles. La popularité d'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 "moi aussi" Spring qui cherchent à monter dans le train du printemps).
Le seul véritable avantage 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 énorme communauté parce que 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 non - c'est extrêmement efficace). (Edit: Signifie que c'est extrêmement flexible, pas qu'il n'est pas aussi efficace.)
La petite taille et le manque de dépendances de Pico est une victoire MAJEURE à ne pas sous-estimer. Combien de mégas devez-vous télécharger pour utiliser Spring maintenant? C'est un kludgy-mess d'énormes fichiers jar, avec toutes ses dépendances. Pensée de manière intuitive, une solution aussi efficace et "petite" devrait évoluer et fonctionner mieux que quelque chose comme Spring. Le ballonnement de Spring va-t-il vraiment améliorer l'échelle? Est-ce que ce monde bizarro? Je ne ferais pas d'hypothèse que Spring est "plus évolutif" jusqu'à ce que cela soit prouvé (et expliqué).
Parfois, créer quelque chose de bien (Pico/Guice), puis garder vos mains hors de lui au lieu d'ajouter des fonctionnalités de ballonnement et d'évier de cuisine avec de nouvelles versions sans fin fonctionne vraiment ...
REMARQUE: il s'agit plus d'un commentaire/d'une diatribe que d'une réponse
PicoContainer est génial. Je reviendrais dessus s'ils voulaient simplement réparer 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é converties automatiquement à partir du contenu plus ancien.
- http://picocontainer.codehaus.org/ Ce qui semble figé dans le temps à la version 2.10.2 - Ce serait vraiment sympa 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 v 1.x, mais il ne dit cela nulle part 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 le printemps l'a fait au début.
Mise à jour: J'ai posté un commentaire aux gens de Pico Container et ils ont apporté quelques améliorations au site Web. Beaucoup mieux maintenant !
C'est une vieille question, mais aujourd'hui, vous pouvez envisager Dagger ( https://github.com/square/dagger ) dans votre Android App. Dagger fait la génération de code sur le temps de compilation. Vous obtenez donc 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 . 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 d'utiliser CDI à la place, 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 pot 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();
}