Why use CDI in Java EE

Question

I know that there are many articles that explain how to use CDI in Java EE, but it's hard for me to understand what benefits this brings. For example, suppose I have a class that currently uses an instance of Foo. I could do

Foo myFoo = new Foo(); 

or

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

I keep reading what with CDI I can do:

 @Inject Foo myFoo; 

but why is it better than the previous factory based approach? I assume there is another use case that I don’t know about, but I could not identify it.

If I understood the answers below, the concept is that the DI structure acts as the main factory object, which is centrally configured. Is this a reasonable interpretation?

Update

Since then, I started learning Spring, and now it makes a lot more sense. The following paragraph is taken from Spring in Practice using the AccountService class as an AccountService , which in turn uses an instance of AccountDao . I apologize for the long quote, but I think it really depends on why the resources invested offer something along standard initialization.

You could create an AccountService using a new keyword, but creating service-level objects is rarely that simple. They often depend on DAOs, senders, SOAP proxies, and more. You could programmatically create each of these dependencies in the AccountService constructor (or through static initialization), but this leads to hard dependencies and cascading changes as they are replaced.

In addition, you can create dependencies from the outside and install them in the AccountService using setter methods or constructor arguments. This will eliminate the hard internal dependencies (if they were declared in the AccountService interface by interface), but you duplicate the initialization code anyway. Here's how you create a DAO and hook it up to your AccountService 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> 

AccountService beans as described above, your program can now request an instance of AccountService from the ApplicationContext Spring, and the Spring DI environment will make sure to instantiate everything that is required to create the instance.

Answer 1

The people who wrote the CDI gave you one big factory object; they have done a better job for you than you. This is an XML configuration or annotation, so you don’t need to embed everything in your code.

Dependency injection engines like Spring do a lot more than your factory. Duplicating everything they offer requires several factory classes and one line of code.

Of course you do not need to use it. You can always invent your own wheel. And you must - if your goal - learn how to make wheels or eliminate addictions.

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

The original article on dependency injection was written by Martin Fowler. I would recommend reading it; that's great eight years later.

"still unclear the more"

Here are a few benefits:

• Loose connection
• Easier testing
• Layer enhancement
• Interface design
• Dynamic proxies (segue to AOP).

Answer 2

The purpose of using dependency injection is that the code using the entered thing has no factory dependency. With your factory code example, there is a static method code built into the code that is not needed there with the DI approach.

What myFoo does not need to know about factory.

Answer 3

At a high level, as in most cases on CompSci, it offers a level of indirection (or abstraction) that would otherwise be hard-coded in your application as Foo myFoo = new Foo(); . This indirect relation leads to loosely coupled code that makes things modular, making it easier to replace, maintain, test classes and subsystems with other classes.

Note that there are many constructions and patterns for indirect / abstraction - dependency injection is just one.

Another aspect of your question: "Why CDI?" “Good, because someone has already done the work for you.” You can always create your own things, but it’s usually a waste of time when the goal is to create a real-world system that must be carried out within the budget and on time. Why worry about food and cooking when there is a Michelin chef who is ready to do the job for you?

Answer 4

This is an important and subtle question about what corporate programming is.

The name is well chosen: contexts and dependencies.

CDI has nothing to do with better or cleaner code, which means that large organizations can create complex, distributed software systems and share data. This means that they are 100% certain that governments or other bureaucracies can indiscriminately distribute stand-alone, well-documented packages for each software they manage. Remember that almost any POJO can be entered these days.

Suppose you are creating some kind of client application and you want it to print the first username in the corner.

• The architects of the enterprise of this large company would like you to have such an opportunity, but as a junior software engineer, there is no chance to get the keys to the database.

• They would also like to protect data over the network, but the company does not pay engineers to reorganize the client authentication each time they need to share a data record.

• They would like you to be able to request and update this information, but they would like transactions to be processed at a higher level than any application.

• They would like you to be able to test your classes with trivial layouts in customization blocks.

• They would like classes to include a minimum of static methods.

• And further and further ...

Most JSRs probably have "EAs would like to be able to ..." somewhere out there somewhere.

CDI is preferable because it allows applications with large (arbitrary?) Horizontal and vertical scales to exchange contexts, dependencies, and therefore data.

In the words of Fowler:

"The problem is, how can I make this reference so that my lister class ignores the implementation class, but can still talk to do its job."

"But if we want to deploy this system in different ways, we need to use plugins to interact with these services so that we can use different implementations in different deployments."

"The approach used by these containers is to ensure that any user of the plugin follows some conventions that allow a separate assembler module to implement the implementation in the lister."

In a nutshell, they allow you to centrally “command and manage” complex enterprise applications. Java EE is a systematic, robust abstraction process, and CDI is an incarnation that works so well that it almost makes it invisible. This makes stitching complex applications almost trivial.

Two more things:

• Note that CDI exists peacefully next to the “service locator pattern” known as JNDI in Java EE, which is preferable if the client’s developer needs to choose from a variety of identically typed alternatives.

• CDI is more firepower than is necessary in many cases, especially in the case of non-entrepreneurship (literally).