Why use CDI in Java EE

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).

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 your options for testing that aren't there with DI.

This is an important and subtle question about what enterprise programming is all about.

The name is well chosen: contexts and dependencies.

CDI has nothing to do with better or cleaner code, it's about ensuring that large organizations can build complex, distributed software systems and share data. It's about making 100% sure that governments or other bureaucracies can indiscriminately distribute self-contained, well-documented packages for every piece of software they control. Remember that these days, virtually any POJO can be injected.

Let's say you're building a client app of some sort, and you want it to print the first name of the user in the corner.

• The enterprise architects of this large company would like you tohave this capability, but as a junior software engineer, there is nochance of you being handed the keys to the DB.

• They would also like to secure the data across the network, but thecompany isn't paying any engineers to re-engineer an authenticationclient every time they need to share a scrap of data.

• They would like for you to be able to be able to query and updatethis info, but would like transactions to be handled at a higherlevel than any one app.

• They would like for you to be able to test your classes with trivial mocks in setup blocks.

• They would like for coupling between classes to involve a minimum of static methods.

• And on and on and on...

Most JSRs probably have a "EAs would like to be able to..." buried inside somewhere.

CDI is preferred because it allows apps of large (arbitrary?) horizontal and vertical scales to share contexts, dependencies, and therefore data.

In Fowler's words:

"The problem is how can I make that link so that my lister class is ignorant of the implementation class, but can still talk to an instance to do its work."

" But if we wish to deploy this system in different ways, we need to use plugins to handle the interaction with these services so we can use different implementations in different deployments."

"The approach that these containers use is to ensure that any user of a plugin follows some convention that allows a separate assembler module to inject the implementation into the lister."

In a nutshell, they allow for centralized "command and control" of complex enterprise applications. Java EE is a systematized, reliable process for abstraction and CDI is a an incarnation of it that works so well, it almost makes it invisible. It makes the stitching together of complex apps almost trivial.

Two more things:

1. Note that CDI exists peacefully alongside the "service locator pattern", known as JNDI in Java EE, which is preferable if the client developer will need to choose among many identically-typed alternatives.

2. CDI is more firepower than is needed in many cases, especially non-enterprise (literally) cases.