2011-04-13 4 views
2

J'apprends le printemps en utilisant des recettes de printemps. A partir de maintenant j'ai compris que nous pouvons injecter des dépendances en utilisant Setter Injection ou Injecting via le constructeur. Ma question est, dans les applications du monde réel quelle méthode est utilisée le plus souvent et pourquoi? Je sais que c'est une question subjective, mais je ne peux pas penser à un meilleur endroit que ce site pour obtenir des idées parfaites. Merci encore.Injection de dépendance de ressort

+0

La méthode est 3.: Vous pouvez diriger l'injection dans les champs. – Ralph

Répondre

4

L'injection de constructeur est préférable à l'injection de setter car elle définit clairement les dépendances nécessaires et vous oblige à les fournir avant de pouvoir créer une instance de la classe. Avec l'injection de setter, l'appelant doit déterminer quelles dépendances sont nécessaires et peut conduire à des situations où l'appelant ne parvient pas à injecter toutes les dépendances nécessaires. Cependant, dans certains cas, vous devrez utiliser l'injection de setter, par exemple traiter des objets n'ayant qu'un constructeur par défaut, ou définir des dépendances où il pourrait y avoir une relation bidirectionnelle. En cas de doute, essayez d'utiliser l'injection du constructeur et ne retombez sur les setters que lorsque cela est nécessaire.

+0

Merci Andy .... – t0mcat

+0

Un bonus supplémentaire est que les objets que vous injectez peuvent être 'final' s'ils sont injectés par le constructeur. – Andrew

2

L'injection de constructeur est considérée meilleure que l'injection de setter pour de nombreuses raisons, car l'injection du constructeur garantit que toutes les propriétés obligatoires sont satisfaites et qu'il est tout simplement impossible d'instancier un objet dans un état invalide. S'il vous plaît voir ce poste pour un exemple: http://www.redcode.nl/blog/2010/09/setter-vs-constructor-injection/

+0

Merci Anubhava – t0mcat

0

Je préfère l'injection de constructeur moi-même. J'utilise Spring depuis 2005.

+0

Merci Duffymo .. – t0mcat

2

Les autres réponses sont déjà très propres sur le fait, que l'injection du constructeur est plus sauvegardée, en termes d'oublier de définir un champ. - Vous pouvez simplement ne pas créer l'instance sans le champ. Donc, un conseil de ces déclarations pourrait être: utiliser l'injection du constructeur pour les champs obligatoires et l'injection de setter ou de champ pour les champs optionnels.

et injection Constructor a deux autres impacts:

  • les champs peuvent être final - (J'aime champs final, parce que la faciliter la compréhension)
  • vous ne pouvez pas construire des cercles de classes. (A.b et B.a) - Le printemps ne peut pas instancier cette construction. (* D'un point de vue architectural, je pense que c'est un pro de l'injection de constructeur, pas un con)

Mais d'un autre côté, si vous utilisez l'injection de constructeur, vous devez écrire plus de code que nécessaire.

public class FieldInjection { 
    @Ressource //the same like @Autowired(required=true) 
    private MyService myService; 
} 

est beaucoup plus courte que:

public class MethodInjection {  
    private final MyService myService; 

    public MethodInjection(final MyService myService) { 
    assert(myService != null); 
    this.myService = myService; 
    } 
} 

Les autors des autres réponses me haïr pour cette déclaration.

Je personnellement crois que lorsque vous avez une classe, qui est seulement utilisé comme Bean Spring (mais pas sans ressort), vous pouvez utiliser l'injection sur le terrain sans que le doute de la sécurité! - Parce que Spring ne mettra le Bean dans son cycle de vie que s'il peut définir tous les champs annotés par @Ressource ou @Autowired(required=true). Pour cette raison, je préfère l'injection sur le terrain car elle rend mon plus rapide (moins à écrire et de moins à lire). Et pour toutes les choses d'initialisation, j'utilise @PostConstruct.(Bien sûr, vous ne pouvez pas utiliser les champs dans le constructeur et vous ne pouvez pas vraiment les mélanger tous les deux.) - Cela lie mon application beaucoup plus fort à un conteneur IOC qu'au constructeur injetion, mais ce n'est pas un problème pour mon utilisation. - Peux-tu jeter un oeil à la norme EJB 3.1, ils n'ont pas du tout d'injection de constructeurs.

0

Il sont les avantages et les inconvénients de chaque façon. Je soutiendrais que l'injection de dépendance basée sur le constructeur est moins sujette aux erreurs, parce que vous imposez certaines règles et dites à votre classe les dépendances dont ses méthodes ont besoin. Plus important encore, l'injection du constructeur impose l'ordre d'initialisation et empêche les dépendances circulaires. Avec l'injection de setter, il n'est pas clair dans quel ordre les choses doivent être instanciées et quand le câblage est fait.

D'autre part, il y a des raisons pour lesquelles l'injection de setter gagne. Les tests unitaires sont toujours plus faciles si les constructeurs sont simples et font moins, ou ne font rien du tout. En outre, toutes les méthodes d'une classe ne requièrent pas les mêmes dépendances. Si vous utilisez le conteneur Spring pour injecter vos dépendances, vous n'avez pas à vous soucier de cela car le conteneur Spring appellera automatiquement vos setters si vous le configurez correctement.