Why use CDI in Java EE

Question

I know there are a lot of articles out there that explain how to use CDI in Java EE but I'm having trouble figuring out what advantage this actually brings. For example, suppose I have a class that currently uses an instance of Foo. I might either do

Foo myFoo = new Foo(); 

or

// Better, FooFactory might return a mock object for testing     Foo myFoo = FooFactory.getFoo(); 

I keep reading that with CDI I can do:

@Inject Foo myFoo; 

but why is this better than the previous factory based approach? I assume there is some other use case that I'm not aware of but I haven't been able to identify this.

If I've understood the responses below, the concept is that the DI framework acts as a master object factory that is configured centrally. Is this a reasonable interpretation?

Update

I've since started learning Spring and this now makes a lot more sense. The paragraph below is taken from Spring in Practice taking an example of an AccountService class which in turn, uses an instance of AccountDao. I apologise for the long quote but I think it really gets to the heart of why injected resources offer something over standard initialisation.

You could have constructed the AccountService using the new keyword, but the creation of service layer objects is rarely so straightforward. They often depend on DAOs, mail senders, SOAP proxies, and whatnot. You could instantiate each of those dependencies programmatically in the AccountService constructor (or through static initialization), but that leads to hard dependencies and cascading changes as they’re swapped out.

Additionally, you could create dependencies externally and set them on the AccountService via setter methods or constructor arguments. Doing so would eliminate the hard internal dependencies (as long as they were declared in the AccountService by interface), but you’d have duplicated initialization code everywhere. Here’s how you create a DAO and wire it up to your AccountService the Spring way:

<bean id="accountDao" class="com.springinpractice.ch01.dao.jdbc.JdbcAccountDao"/>  <bean id="accountService"     class="com.springinpractice.ch01.service.AccountService">     <property name="accountDao" ref="accountDao"/> </bean> 

Having configured the beans as above, your program can now request an instance of AccountService from the Spring ApplicationContext and the Spring DI framework will look after instantiated everything that needs instantiating.

Answer 1

The people that wrote CDI gave you one big object factory; they did the work for you, better than you would. It's XML configuration or annotation driven, so you don't have to embed everything in code.

Dependency injection engines, like Spring, do a lot more than your factory. It'll take more than one factory class and one line of code to duplicate all that they offer.

Of course you don't have to use it. You are always free to invent your own wheel. And you should - if your purpose is to learn how to make wheels or eliminate dependencies.

But if you want to just develop applications, it's better to use the tools that others provide when they give you an advantage.

The seminal article on dependency injection was written by Martin Fowler. I'd recommend reading it; it's still great, eight years later.

"still not clear on what the more is"

Here are a few advantages:

1. Looser coupling
2. Easier testing
3. Better layering
4. Interface-based design
5. Dynamic proxies (segue to AOP).

Answer 2

The purpose of using dependency injection is so that the code using the thing that's injected doesn't have a dependency on the factory. With your factory code example there's a static method call embedded in your code that is not needed there with the DI approach.

The thing that is being injected with myFoo shouldn't have to know about the factory. The factory puts limits on your options for testing that aren't there with DI. Specifically if you have a Bar object that has a Foo, a test of that Bar object can directly create a Foo or mock Foo and put it on the Bar without needing to involve a FooFactory, and you don't have to write a FooFactory, which is boilerplate that doesn't do anything to implement application business logic.