web-dev-qa-db-fra.com

Devrais-je utiliser @EJB ou @Inject

J'ai trouvé cette question: Quelle est la différence entre @Inject et @EJB mais je ne suis pas devenu plus sage. Je n’ai jamais utilisé Java EE auparavant et je n’ai pas d’expérience en matière d’injection de dépendances. Je ne comprends donc pas ce que je devrais utiliser.

Est-ce que @EJB et l'ancienne méthode d'injection? L'injection est-elle effectuée par le conteneur EJB lors de l'utilisation de cette annotation lors de l'utilisation de @Inject utilise-t-il le nouveau framework CDI? Est-ce la différence et devrais-je utiliser @Inject au lieu de @EJB si c'est le cas?

javajava-eeejbcdi
137
LuckyLuke

Le @EJB est utilisé pour injecter uniquement des EJB et est disponible depuis un certain temps déjà. @Inject peut injecter n'importe quel bean géré et fait partie de la nouvelle spécification CDI (depuis Java EE 6).

Dans des cas simples, vous pouvez simplement changer @EJB en @Inject. Dans des cas plus avancés (par exemple, lorsque vous dépendez fortement d'attributs de @EJB tels que beanName, lookup ou beanInterface), il vous faudrait définir un champ ou une méthode @Inject pour utiliser @Producer.

Ces ressources peuvent être utiles pour comprendre les différences entre @EJB et @Produces et pour en tirer le meilleur parti:

Le blog d'Antonio Goncalves:
CDI Partie I
CDI Partie II
CDI Partie III

Documentation JBoss Weld:
CDI et l'écosystème Java EE

StackOverflow:
Injecter le bean @EJB en fonction des conditions

168
Piotr Nowicki

@Inject peut injecter n'importe quel bean, alors que @EJB peut uniquement injecter des EJB. Vous pouvez utiliser l'un ou l'autre pour injecter des EJB, mais je préférerais @Inject partout.

30
Bozho

Mise à jour: Cette réponse peut être incorrecte ou obsolète. S'il vous plaît voir les commentaires pour plus de détails.

J'ai changé de @Inject à @EJB car @EJB permet l'injection circulaire alors que @Inject vomit dessus.

Détails: J'avais besoin de @PostConstruct pour appeler une méthode @Asynchronous, mais cela se ferait de manière synchrone. La seule façon de faire l'appel asynchrone était de faire en sorte que l'appel d'origine soit la méthode d'un autre bean et de le rappeler à la méthode du bean d'origine. Pour ce faire, chaque grain avait besoin d'une référence à l'autre - donc circulaire. @Inject a échoué pour cette tâche alors que @EJB fonctionnait. 

12
necromancer

Voici une bonne discussion sur le sujet. Gavin King recommande @Inject sur @EJB pour les EJB non distants. 

http://www.seamframework.org/107780.lace

ou 

https://web.archive.org/web/20140812065624/http://www.seamframework.org/107780.lace

Re: Injecter avec @EJB ou @Inject?

  1. Nov 2009, 20:48 America/New_York | Lien Gavin King 

Cette erreur est très étrange, car les références locales des EJB doivent toujours être sérialisable. Bug dans Glassfish, peut-être?

En gros, @Inject est toujours meilleur, puisque:

it is more typesafe,
it supports @Alternatives, and
it is aware of the scope of the injected object.

Je recommande de ne pas utiliser @EJB, sauf pour déclarer des références à EJB distants.

et

Re: Injecter avec @EJB ou @Inject?

  1. Nov 2009, 17:42 America/New_York | Lien Gavin King

    Est-ce que cela signifie mieux @EJB avec les EJB distants? 

Pour un EJB distant, nous ne pouvons pas déclarer les métadonnées comme des qualificateurs, @Alternative, etc., sur la classe de haricot, puisque le client n'est tout simplement pas va avoir accès à ces métadonnées. En outre, certains supplémentaires les métadonnées doivent être spécifiées, ce dont nous n'avons pas besoin pour le cas local (nom JNDI global de quoi que ce soit). Donc, tout ça doit partir ailleurs: à savoir la déclaration @Produces.

11
John Manko

Il peut également être utile de comprendre la différence de terme entre l'identité de bean session en utilisant @EJB et @Inject . Selon les spécifications, le code suivant sera toujours true:

@EJB Cart cart1;
@EJB Cart cart2;
… if (cart1.equals(cart2)) { // this test must return true ...}

Utiliser @Inject au lieu de @EJB n’est pas la même chose.

voir aussi identité de beans session sans état pour plus d'informations

3
ken

L'injection existait déjà dans Java EE 5 avec les annotations @Resource, @PersistentUnit ou @EJB, par exemple . Mais elle était limitée à certaines ressources (source de données, EJB. sauvegarde haricot ...). Avec CDI, vous pouvez injecter n'importe quoi n'importe où grâce à l'annotation @Inject.

0
javierZanetti