Guice de l'injecteur.getInstance() - bonne pratique?

Disons que j'ai deux applications de partage de la même bibliothèque. Cette bibliothèque contient les classes comme DAOs, Utils, etc. Tout dans la bibliothèque partagée est câblé avec Guice. Mes deux applications dépendent de cette bibliothèque, mais n'ont pas de dépendance directe sur Guice.

 ______    ______    ______
|      |  |      |  |      |
| APP1 |->| LIB  |<-| APP2 |
'------'  '------'  '------'

Actuellement, je utiliser quelque chose comme ceci:

static <T> Utils.getInstanceOf (Class<T> type);

qui est tout simplement un wrapper pour:

injector.getInstance (Class<T> type);

Mais la guice docs disent:

Lorsque cela est possible, évitez d'utiliser cette méthode, en faveur d'avoir Guice
injecter des dépendances à l'avance.

Alors, quel est le meilleur moyen de donner de l'injection de dépendance pour les deux applications sans avoir à manuellement les lier dans un Guice module?

Est-ce que votre règle de conception de l'utilisation de @Inject?
Pas du tout. Je l'utilise tous les plus partagés lib. J'ai oublié de mentionner que les applications clientes ont des servlets et Jersey RESTE classes en eux - je.e webapps exécute dans un conteneur de servlet (non JavaEE).

OriginalL'auteur albogdano | 2013-10-11

9

Alors, quel est le meilleur moyen de donner de l'injection de dépendance pour les deux
les applications sans avoir à manuellement les lier dans un Guice module?

Il n'existe pas de telle façon. Vous embrassent Guice totalement ou ne pas l'utiliser et de transmettre vos dépendances explicitement. Eh bien, de structurer votre code dans une telle façon afin de ne pas créer directement de la classe dépendances, en passant entre eux, au contraire, par un constructeur, peut aussi être appelé "l'injection de dépendance", mais je suis sûr que ce n'est pas ce que vous voulez dire. Si vous ne souhaitez pas utiliser Guice dans vos applications, vous ne serez pas en mesure d'obtenir quelque chose de mieux que getInstance(), ce qui est laid, surtout parce que vous êtes à l'aide de statique wrapper.

Idéalement votre bibliothèque doit fournir un module que vous pouvez installer via Guice.createInjector() dans vos applications, ou, à l'inverse, la bibliothèque doit fournir une Injector exemple que vous pouvez utiliser dans vos applications en utilisant createChildInjector() et de fournir à l'application de modules spécifiques. Légère modification de cette approche est le passage d'application des modules spécifiques à la bibliothèque de sorte qu'ils seront utilisés pour créer Injector. J'ai récemment écrit Guice API basée sur la coutume de servlet-comme l'interface qui ne prend pas en charge tout type de DI à l'aide de la dernière approche, et il fonctionne parfaitement.

Il n'est pas du tout difficile à utiliser Guice dans le servlet ou Jersey de l'environnement. Ce dernier, par exemple, a out-of-the-box intégration avec Guice (au moins, dans 1.x versions). Guice servlet extension est également très bon et pratique. Il suffit de l'essayer et de voir par vous-même.

Donc c'est OK pour passer un Injector exemple autour? J'essayais de l'éviter.
Non-non-non. Je ne voulais pas dire ça. Je pense que je n'ai pas à me faire comprendre et probablement fait une erreur. J'ai mis à jour la réponse.
Il fait plus de sens maintenant, grâce Vladimir!

OriginalL'auteur Vladimir Matveev
3

static <T> Utils.getInstanceOf (Class<T> type);

Ce que vous avez terminé avec est un Service Locator.

Tandis que dans un petit nombre de cas, ce qu'il est acceptable pour les injector à s'échapper dans les autres creational objets, je ne pense pas que ce l'un d'entre eux. Vous avez terminé avec tous les inconvénients d'un Localisateur de Service et de tous les avantages peut être obtenu en utilisant l'outil que vous utilisez déjà.

OriginalL'auteur Michael Lloyd Lee mlk
2

Du cadre "habituel" de l'aide d'un injecteur est à mettre en place dans certains de haut niveau du point d'entrée de votre projet (dans un servlet scénario, à l'aide de Guice-Servlet, ce serait la GuiceServletContextListener). Vous souhaiterez peut-être configurer un individu de l'injecteur à un point d'entrée pour certains de dépendance et de le rendre responsable de câblage de cette dépendance, pour l'amour de la modularisation. Si vous souhaitez à la fois individuel, les liaisons et les fixations de la mère de projet, dans vos dépendances, que vous pouvez créer un enfant injecteur qui délègue à son parent si aucune liaison n'est trouvé. Guice prend en charge cette.

Cependant, il semble étrange pour moi que vous voulez mettre en place un injecteur à l'intérieur d'une dépendance et à utiliser dans votre application principale(s). Cela signifie que la dépendance connaît toutes les liaisons nécessaires par l'application principale(s). Je ne suis pas tout à fait sûr de ce que vous essayez d'atteindre avec cette approche. Est-ce que vos deux applications ont la même ou très proche de liaison de l'installation et que vous ne voulez pas répéter? Dans ce cas, vous devez définir un module avec tout ce que les liaisons configurations une fois (peut-être dans une dépendance) et de l'utiliser lors de la configuration de l'injecteur à l'entrée des points de chacune de vos applications. Beaucoup à l'égard de votre scénario.

À votre question en général. Je pense qu'il est de bonne pratique d'éviter explicitement passage de l'injecteur. Chaque fois que vous faites cela, vous travaillez à l'encontre de l'idée de l'injection de dépendance comme étant un projet transparent et vous attachez-vous à une injection de béton cadre. Dans la plupart des cas, vous pouvez éviter les références explicites à l'injecteur par l'aide d' Les fournisseurs de et Les usines.

Merci! J'ai surtout essayer de ne pas répéter le code et ont également un module par défaut dans la lib, contenant les liaisons pour les implémentations par défaut de l'interface. Les principales applications ne fournissent pas leurs propres modules et des liaisons encore. Donc dans un sens partagé lib connaît toutes les liaisons par défaut utilisé dans d'autres applications.
Vous vous dites "encore" implique qu'il peut être individuelle des liaisons dans l'avenir. Ce qui est parfaitement bien et peut facilement être atteint, étant donné que les applications de créer leur propre injecteur, en utilisant le module commun. Je vois injecteur de code de configuration comme un fichier de configuration: Il est parfaitement normal de changer, il devrait être situé dans l'application qu'il configure -- parce que c'est là que je recherche pour lui-même, et il devrait être dans une classe qui ne fait rien d'autre que de la configuration.

OriginalL'auteur Sven Amann
2

Si vous avez une méthode qui a besoin de créer une nouvelle instance de la classe C au moment de l'exécution, se lier à un Fournisseur pour votre classe. C serait lié à la manière habituelle, par exemple
```
public CModule extends AbstractModule {
    @Overide
    public void configure() {
        bind(C.class).to(CImpl.class);
    }
}
```
La classe qui crée C instances ressemblerait à ceci:
```
class UserOfC {
    private Provider<C> cProvider;
    ...

    @Inject
    UserOfC(Provider<C> cProvider, ...) {
        this.cProvider = cProvider;
        ...
    }

    public void doSomethingWithAC (...) {
        C myC = cProvider.get();  //not a singleton; new instance created!
        ...
    }
}
```
Guice membres Fournisseur d'injection gratuit pour rien. Si C est lié, vous pouvez injecter un Fournisseur aussi facilement que vous pouvez injecter une instance de C.

Autres Suggestions:

Je recommande fortement que vous injecter toutes les dépendances à la construction, si cela est possible, même si elle nécessite l'écriture d'un peu plus de lignes de code. J'ai utilisé Guice pendant des années, et n'ont pas besoin partielle de la construction ou de toute autre fonctionnalité avancée.

Quand je suis confronté à la nécessité pour une partie d'injection, de manière générale, j'écris mon propre usine. Je trouve ça beaucoup plus facile à comprendre et à déboguer quand j'ai écrit le code.

OriginalL'auteur Eric Mintz
0

Ouais, il est ok pour passer de l'injecteur de cette façon.

Même nous avons fait quelque chose de similaire avec notre guichet d'application, donc pour les non-guichet pages, nous avons simplement utilisé injector.get.inject(this) et adopté dans le constructeur.

et il fonctionne parfaitement.

Espère que cette aide.

OriginalL'auteur Ashish

Vous devez vous connecter pour publier un commentaire.