Il y a deux façons de pouvoir obtenir une instance EJB: p>
Quelles sont les différences, les implications et les gotchas à l'aide de l'une de ces approches? Sont-ils les mêmes? L'injection de dépendance est-elle plus rapide que la recherche? Qu'en est-il de la gestion de la transaction et de la gestion du cycle de vie d'objet? P>
Des choses dont je suis au courant comprennent: p>
Annotation p>
recherche p>
3 Réponses :
Recherche dépend de la présence de la mise en œuvre JNDI, c'est-à-dire que vous devez configurer la mise en oeuvre JNDI afin d'exécuter des tests d'unité, puis des champs annotés peuvent être configurés manuellement. P>
Les deux atteignent le même résultat. C'est plus une question de couplage fort>. Avec l'annotation, vous obtenez un couplage lâche et il est plus facile de moquer et de tester. Avec la recherche directe, vous dépendez du contexte initial qui peut être parfois peu pratique. p>
imho recherche ne fonctionne pas partout fort>. Par exemple, dans Glassfish, une recherche sur une EJB locale d'un pojo ne fonctionnera que si elle a été "importée" précédemment avec Mon conseil serait: utiliser l'annotation autant que possible. Si un pojo a besoin d'une référence à un EJB, passez-le comme paramètre (par exemple dans le constructeur). Cela s'appelle l'inversion de dépendance et est de toute façon une bonne pratique. P> @ejbs (...) code> sur l'une des beans de session qui utilise le pojo. Voir Cette discussion . Vous devez comprendre la différence entre les local local strong> et JNDI global strong> pour cela. p>
Je pense que c'est gentil un dur de se moquer de JJB annoté. Lorsque vous utilisez la recherche, vous pouvez construire un commutateur en fonction de votre environnement (test -> loginmockbean, production -> loginbean). P>
C'est juste faux. Si cela est injecté par le conteneur, cela signifie que vous pouvez plus facilement l'injecter vous-même dans les tests, par exemple Mybean Bean = Nouvelle mybean (); haricot.Injectbean = nouveau moqueur () code>. L'accrochage dans la recherche est plus compliqué, surtout si le code dépend de
nouvel initialContext () code>. Comment rendez-vous une version spéciale du contexte pour vos tests?