Pourquoi utiliser/développer Guice, alors que vous avez Spring et Dagger ?

Question

A ma connaissance, Dagger génère du code, alors que Guice et Spring s'appuient sur le traitement en cours d'exécution, Dagger est donc plus rapide, mais nécessite plus de travail de la part du programmeur. Dagger est donc plus rapide, mais nécessite plus de travail de la part du programmeur. En raison de son avantage en termes de performances, il convient au développement mobile (Android).

Cependant, lorsqu'il nous reste Guice et Spring, ce dernier a beaucoup d'intégrations. Quel est l'intérêt de développer/utiliser Guice, si l'on peut utiliser Spring Framework (qui fait à peu près la même chose, mais offre par exemple un accès plus facile à la base de données) ?

Google n'essaie-t-il pas de réinventer la roue en créant son propre outil DI, au lieu d'utiliser (et éventuellement de contribuer à) Spring Framework ?

Je cherche un arbre de décision qui me guide dans le choix de l'outil DI.

Answer 1

Il est important de reconnaître que Dagger a été créé après Guice, par l'un des créateurs de Guice ( "Crazy Bob" Lee ) qui a déménagé à Square :

• Rod Johnson publié à l'origine Printemps en Octobre 2002 avec son livre Conception et développement J2EE par des experts indépendants Spring a ensuite été rendu public sous licence Apache en juin 2003 et en tant que v1.0 en juin 2003. Mars 2004 .
• Google a publié à l'origine Guice publiquement en Mars 2007 .
• JSR-330 formalisé javax.inject annotations en Octobre 2009 Le groupe d'experts est composé de représentants de Google (Bob Lee) et de SpringSource (Rod Johnson), ainsi que d'autres collaborateurs de l'industrie.
• Square a publié à l'origine Poignard 1 publiquement en Mai 2013 .
• Google a publié à l'origine Poignard 2 publiquement en Avril 2015 .
• Square a marqué Dagger 1 comme obsolète 10 jours avant que cette question ne soit posée, le 15 septembre 2016 .

En ce sens, la conservation continue de Guice n'est pas tant une "réinvention de la roue" qu'une maintenance d'un logiciel de longue date et largement consommé, bien antérieur à toute version de Dagger. On peut considérer Dagger comme un successeur spirituel de Guice, mais qui n'offre qu'une version de Dagger. sous-ensemble optimisé de la fonctionnalité de Guice.

Pour énumérer et amender les différences que vous avez mentionnées ci-dessus :

• Spring est un cadre relativement lourd avec de nombreuses intégrations, un langage de configuration XML et des liaisons d'exécution/réflexion. Les applications qui utilisent déjà Spring peuvent utiliser le cadre d'injection de dépendances de Spring avec très peu de travail supplémentaire.
• Guice est un cadre relativement léger avec moins d'intégrations, de configuration d'instances Java et de liaisons d'exécution/réflexion. L'utilisation des liaisons Java permet de vérifier les types à la compilation et d'intégrer l'autocomplétion de l'IDE.
• Dagger est un cadre très léger avec très peu d'intégrations, une configuration d'interface/annotation Java et des liaisons générées par le code à la compilation. L'aspect de la génération de code rend Dagger très performant dans l'ensemble et en particulier dans les environnements mobiles et à ressources limitées. (Les VM d'Android diffèrent des JRE de serveur d'une manière qui rend la réflexion particulièrement lente, de sorte que Dagger est particulièrement utile ici).
• Les trois frameworks susmentionnés prennent en charge la norme JSR-330, de sorte qu'une bibliothèque ou une application bien conçue peut être pratiquement indifférente au conteneur DI utilisé.

En outre, gardez un œil sur les modèles et les politiques de maintenance/dépréciation de tout cadre que vous utilisez. En fonction des connaissances et de l'expérience de votre équipe, de vos besoins en matière de réflexion ou de configuration de l'exécution, et de vos besoins en matière d'intégration et de performance de l'exécution, vous verrez probablement l'un des frameworks ci-dessus se démarquer. Cela dit, il existe également d'autres frameworks, alors gardez l'œil ouvert sur les nouvelles options et les forks des frameworks ci-dessus.