What are the advantages of a dependency injection framework over classical dependency injection?

user_4011408 0
Viewed 208

I am struggling to understand the benefits of using a dependency injection framework, in my case CDI in a Jakarta EE context.

I think I see the point of the standard use case for dependency injection - it is often benefitial to "factor out" the concrete instantiation of an instance variable, so that

public class Car {
    private Tyre tyre;

    public Car() {
        tyre = new Tyre();
    }
}

becomes

public class Car {
    private Tyre tyre;

    public Car(Tyre tyre) {
        this.tyre = tyre;
    }
}

which has the benefit that now we can insert whatever tyre we like, which is handy for unit tests, for example, as Tyre might be difficult to instantiate.

Now where I am struggling, and I think where many tutorials and questions are a bit thin, is, how you can connect this with a dependency injection framework. Of course, my example would now read (when using CDI)

public class Car {
    private Tyre tyre;

    @Inject
    public Car(Tyre tyre) {
        this.tyre = tyre;
    }
}

but I don't see why I have gained anything at this stage. I am aware that you could have more than one implementation of the Tyre interface, but then you would have to put another annotation on top of the injection to tell the framework which tyre is inserted... how is this any better than just putting the concrete implementation into the signature?

After summing up my current knowledge and thoughts, my question is basically how a baby example of the following progression could look like:

  1. Code without dependency injection and with some problems
  2. Same code with dependency injection where some, but not all problems are solved
  3. Same code with a dependency injection framework (preferrably CDI) where all problems are solved.
cdi jakarta-ee java
2 Answers

I'm not familiar with CDI but I can speak about DI frameworks in general in the context of your example.

Suppose you have SummerTyre and WinterTyre, and you need to use one or the other depending on the Season. Without a DI framework, every class that wants to create a Car will have to depend on the Season, and will have to contain code to create the right Tyres, even though this is essentially an implementation detail of the Car.

What DI frameworks let you do is configure this stuff elsewhere (typically in main or very close to that), so that all your code just depends on a properly configured injector and nothing else.

In this particular case, you'd probably have a SeasonalTyreFactory that is responsible for creating the right kind of Tyre. The Season is injected into this factory, and the injector is configured to call this factory whenever it needs a Tyre. Now any code can request a Car without worrying about whether it's got the right set of Tyres!

user_146370

The only real advantage from the DI perspective is, that you don't have to build the dependency tree yourself.

Going further in your example, we now use the car:

 Tyre myTyre = new Tyre();
 Car theCar = new Car(myTyre);

OK, that's not too overwhelming, but imagine a real application with dozens or hundreds of services, which have their specific dependencies:

 ApplicationConfiguration config = new ApplicationConfiguration(...);
 GeneralDatabaseService dbAccess = new GeneralDatabaseService(conf);
 UserRuleService userRules = new UserRuleService(config);
 UserDatabaseService userDb = new UserDatabaseService(config, dbAccess, userRules);
 ...
 // 100 more lines like this
 ...
 ApplicationEntryPoint app = new ApplicationEntryPoint(conf, userDb, ...);
 app.start();

In a CDI container, the container does all that scaffolding for you, and it boils down to simply do:

container.select(Car.class).get().drive();
// or
container.select(ApplicationEntryPoint.class).get().start();

Apart from that, you have contexts, different scopes for web applications, event handling, interceptors, and so on...

user_55060860
Related