La principale chose que ça apporte déjà c'est que ce n'est pas JavaEE.
En fait le truc c'est surtout qu'on oublie ce truc ignoble qu'est JavaEE. C'est donc très facilement utilisable dans tout et n'importe quoi, pas que dans du web (et on oublie les serveurs d'application, on fait tourner ça dans du jetty qui poutre, on oublie glassfish qui fonctionne quand il veut, qui se debug mal et qui les brises, on fait des choses légère, on prend que ce qu'on veut et pas une stack énorme qui au final est typiquement overingeneered)
Après, qu'il y ait des ressemblances est normal étant donné que Guice est une implémentation de la JSR330 et je pense que dans JEE aussi, non ?
Par contre, il y a beaucoup plus de choses que juste l'implémentation de la JSR et c'est là où il se démarque.
Par contre, je suis surpris tout de même. En quoi les exemples de Guice peuvent faire peur ? C'est une vrai question car j'ai vraiment le sentiment inverse.
Et pour donner un autre avantage de Guice : là où je bosse on utilise beaucoup OSGi. Le problème c'est que à ce moment on se retrouve en quelque sorte avec deux injections. L'injection Guice (ou autre) et l'injection OSGi (avec iPojo - beurk - ou à la mano). Et là où Guice apporte un réel plus, c'est avec Peaberry. A partir de là tous mes services OSGi sont injectables exactement de la même manière que mon classes bindés classiquement dans Guice. Et c'est réellement vraiment pratique. Je trouve qu'on arrive enfin à partir de là à une utilisation potable de Java, beaucoup moins lourde qu'à l'habitude.
[^] # Re: Injection de dépendance
Posté par CrEv (site web personnel) . En réponse au journal De tout, de rien, des liens, du vrac (mais moins bookmarks cette fois). Évalué à 3.
La principale chose que ça apporte déjà c'est que ce n'est pas JavaEE.
En fait le truc c'est surtout qu'on oublie ce truc ignoble qu'est JavaEE. C'est donc très facilement utilisable dans tout et n'importe quoi, pas que dans du web (et on oublie les serveurs d'application, on fait tourner ça dans du jetty qui poutre, on oublie glassfish qui fonctionne quand il veut, qui se debug mal et qui les brises, on fait des choses légère, on prend que ce qu'on veut et pas une stack énorme qui au final est typiquement overingeneered)
Après, qu'il y ait des ressemblances est normal étant donné que Guice est une implémentation de la JSR330 et je pense que dans JEE aussi, non ?
Par contre, il y a beaucoup plus de choses que juste l'implémentation de la JSR et c'est là où il se démarque.
Par contre, je suis surpris tout de même. En quoi les exemples de Guice peuvent faire peur ? C'est une vrai question car j'ai vraiment le sentiment inverse.
Et pour donner un autre avantage de Guice : là où je bosse on utilise beaucoup OSGi. Le problème c'est que à ce moment on se retrouve en quelque sorte avec deux injections. L'injection Guice (ou autre) et l'injection OSGi (avec iPojo - beurk - ou à la mano). Et là où Guice apporte un réel plus, c'est avec Peaberry. A partir de là tous mes services OSGi sont injectables exactement de la même manière que mon classes bindés classiquement dans Guice. Et c'est réellement vraiment pratique. Je trouve qu'on arrive enfin à partir de là à une utilisation potable de Java, beaucoup moins lourde qu'à l'habitude.