Pourquoi utiliser / développer Guice quand vous avez Spring and Dagger?

Question

À ma connaissance, Dagger génère du code, tandis que Guice et Spring s'appuient sur le traitement de l'exécution. Dagger fonctionne donc plus rapidement, mais nécessite davantage de travail du côté du programmeur. En raison des performances, Edge est bon pour le développement mobile (Android).

Cependant, lorsque nous nous retrouvons avec Guice et Spring, ce dernier comporte de nombreuses intégrations. Quel est l'intérêt de développer/d'utiliser Guice, si nous pouvons utiliser Spring Framework (qui fait fondamentalement la même chose, mais offre par exemple un accès plus facile aux bases de données)?

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

Je suis à la recherche d'un arbre de décision, qui guide le choix de l'outil DI.

Answer 1

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

• Le printemps a été initialement publié en octobre 2002 .
• À l'origine, Google publiait Guice publiquement dans mars 2007 .
• JSR-3 formalisé des annotations javax.inject Dans octobre 2009 , avec une contribution importante de Google (Bob Lee), Spring et d'autres acteurs du secteur.
• Square a publié à l'origine Dagger 1 publiquement dans mai 201 .
• Google a initialement publié Dagger 2 publiquement dans avril 2015 .
• Square a marqué Dague 1 comme obsolète 10 jours avant que cette question ne soit posée, le 15 septembre 2016 .

En ce sens, la curation continue de Guice ne "réinvente pas la roue", mais bien la maintenance d'un progiciel de longue durée et largement consommé, antérieur à toute version de Dagger. Vous pourriez considérer que Dagger est un successeur spirituel de Guice, mais qu’il offre uniquement un sous-ensemble optimisé de la fonctionnalité de Guice.

Pour lister et modifier les différences que vous avez ci-dessus:

• Spring est un framework relativement lourd avec de nombreuses intégrations, un langage de configuration XML et des liaisons d'exécution/de réflexion. Les applications utilisant déjà Spring peuvent utiliser le framework d'injection de dépendance de Spring avec très peu de travail supplémentaire.
• Guice est un framework relativement léger avec peu d’intégrations, une configuration d’instance Java et des liaisons d’exécution/de réflexion. Avec l'utilisation des liaisons Java, vous obtenez une vérification de type à la compilation et une intégration IDE à remplissage automatique.
• Dagger est un framework très léger avec très peu d'intégrations, une configuration interface/annotation Java et des liaisons générées par un code à la compilation. La génération de code rend Dagger très performant dans l’ensemble et particulièrement dans les environnements mobiles et à ressources limitées. (Les machines virtuelles Android diffèrent des JRE de serveur de manière à ralentir la réflexion, c'est pourquoi Dagger est particulièrement utile ici.)
• Les trois structures ci-dessus prennent en charge JSR-330. Ainsi, une bibliothèque ou une application bien conçue peut être essentiellement agnostique par rapport au conteneur DI utilisé.

Au-delà de cela, gardez un œil sur les modèles et les règles de maintenance/dépréciation parmi tous les frameworks que vous utilisez. En fonction des connaissances et de l'expérience de votre équipe, de votre besoin de réflexion ou de configuration de l'exécution, ainsi que de votre besoin d'intégrations et de performances d'exécution, vous verrez probablement se distinguer l'un des éléments ci-dessus. Cela dit, il existe également d’autres cadres, alors gardez un œil ouvert sur les nouvelles options et options proposées ci-dessus.