1

I was reading the JavaEE 6 tutorial and, while reading the SessionBean and CDI sections, I came across several doubts.

1) For what I understood, the @EJB annotation injects a SessionBean resulting in a use of the Dependency Inject pattern. I understand that this pattern aims to reverse the responsability of who builds what objects. So, instead of a certain class creating it owns dependencies, it will receive them in the constructor. However, how does the @EJB annotation mitigates the problems of not injecting dependencies? The same goes for the @Inject annotation.

2) I have this utility class (contains only static methods) that formats a date into several formats (yyyy-MM-dd, dd-MM-yyyy, etc...). Is it better to use a Stateless Session Bean for these methods or should I keep the Utility class? In case of using an EJB for this, what is the difference between using it or using a bean by using the @Inject annotation?

3) When using Dependency Injection, does it make sense to use a Service Locator or Factory patterns? (Although I've seen Service Locater being documented as an anti-pattern).

Miguel Ribeiro
  • 8,057
  • 20
  • 51
  • 74

2 Answers2

2

The @EJB and @Inject mitigate the problem of not injecting, by... injecting (duh! ;))

Keep this utility methods in those classes. EJBs are for transaction management, resource usage throtteling, limiting access to methods based on a user's role, etc. None of that seems necessary for your utility methods.

At most you can make that utility class injectable via CDI: define an interface for it and create a producer method. Often even this is overkill, but it depends on the exact extend of your class and its usage.

With injection you can still have factories (the producer is a kind of factory), but the client doesn't explicitly use the factory. The client declares a dependency, and CDI can use the "factory" (producer) to satisfy this.

Mike Braun
  • 3,729
  • 17
  • 15
1

  1. No. Dependency injection is not just about avoiding the creation of its dependencies. It's also about avoiding to ask the container for its dependencies. Instead of asking the container for dependencies, the container injects dependencies into the component. I don't understand what you mean by "the problem of not injecting dependencies". Please clarify.

  2. A session bean is normally used when you need transactional, security and/or remoting aspects to be added by the container around the methods. If it's just a utility class, there's no reason to make it a session bean.

  3. No, it doesn't make sense. Depoendency injection's main goal is to replace the uses of a servce locator and/or factory, in order to have the container inject the dependency into the bean. This is what makes the code easily testablen because you can simply inject fake dependencies (mock objects) into the bean in your unit test.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • What I meant was that how does the EJB annotation makes the class not depending on the bean? What is the main difference of having a this.bean = new Bean(); or @EJB Bean bean? In the end, both implementations will make the class depend on Bean, right? Or am I mixing up concepts here? – Miguel Ribeiro Apr 14 '13 at 17:19
  • The point of dependency injection is not to eliminate dependencies. Its point is to inject them from the outside. This allows manually injecting fake dependencies in unit tests. – JB Nizet Apr 14 '13 at 17:26
  • So, more researching is making me to believe that Dependency Injection actually works more for nothing else than Unit testing to simplify the set of mock beans. I've been trying to understand how it helps beyond that – Miguel Ribeiro Apr 14 '13 at 17:59
  • @MiguelRibeiro "new()" can't be intercepted by the container. With dependency injection *or* at lookup, the container can switch in a proxy, which is what gives EJB and CDI its power. – Mike Braun Apr 15 '13 at 08:40