Dependency injection: should I use a framework?

Question

I have recently worked on a Python project where we did dependency injection heavily (because we must in order for the app to be testable), but we didn't use any framework. At times it was a little tedious to wire up all the dependencies manually, but overall it worked great.

When an object had to be created in multiple places, we simply had a function (sometimes a class method of that object) to create a production instance. This function was called whenever we needed that object.

In the tests, we did the same thing: if multiple times we needed to create a 'test-version' of an object (i.e., a real instance backed by mock objects), we had a function to create this 'test-version' of a class, to be used in tests.

As I said, generally this worked fine.

I am now entering a new Java project, and we are deciding whether to use a DI framework, or do DI manually (like in the previous project).

Please explain how working with a DI framework will be different, and in what manners it is better or worse than manual 'vanilla' dependency injection.

Edit: I would also like to add to the question: have you witnessed any 'professional level' project that does DI manually, without a framework?

Answer 1

The key of DI containers is the abstraction. DI containers abstract this concern for you. As you may guess, it has a noticeable impact on the code, often translated into a fewer number of constructors, setters, factories and builders. In consequence, they make your code more loosely coupled (due to the underlying IoC), cleaner and simpler.

Backgrounds

Years ago, DI required us to write config files (declarative programming). It was fantastic to see the number of LOC diminishing substantially, but while the LOCSs decreased, the number of config files slightly increased. For medium or small projects it was not a problem at all, but for larger projects having the DI scattered between code and several files became a pain in the ... Nonetheless, the main problem was the paradigm itself. It was quite inflexible because the descriptors left little space for customizations.

The paradigm shifted progressively towards to convention over configuration, which trades config files for annotations or attributes. It keeps our code cleaner and simpler while providing us with the flexibility that XML could not. Some DI contianers are programable so the DI graph can change in runtime.

Now, without setters, constructors and XML the application is more than clean. Is also magic.

On the down side...

Convention over configuration makes the abstraction so heavy that you barely know how it works. Sometimes seems magic and here comes one more drawback. Once is working, many developers don't care about how it works.

This is a handicap for those who learnt DI with DI containers. They don't fully understand the relevance of the design patterns, the good practices and the principles that were abstracted by the container. I have asked developers if they were familiarised with DI and its advantages and they answered: -Yes, I have used Spring IoC-. (What the hell does it mean?!?)

One can agree or not with each of these "drawbacks". In my humble opinion, it's a must to know what's going on in your project. Otherwise, we don't have a full understanding of it. Also is to know what DI is for and to have a notion of how to implement it is a plus to consider.

On the plus side...

One word productivity. Frameworks let us focus on what really matters. The application's business.

Despite the commented shortcomings, for many of us (which job is conditioned by deadlines and costs), these tools are an invaluable resource. In my opinion, this should be the main argument in favour of implementing a DI containers.

Testing

Whether we implement pure DI or containers, testing is not going to be a problem. Quite the opposite. The same containers often provide us with the mocks for unit testing out of the box. Along the years I have used my tests as thermometers. They tell me if I have relied heavily on the containers facilities. I say this because the containers I'm used can initialize private attributes without setters or constructors.

Sounds tempting right? Be careful! Don't fall into the trap!

Suggestions

If you decide to implement containers, I strongly suggest sticking with the good practices. Keep implementing constructors, setters and interfaces. Enforce the framework/container to use them. It will make easier possible migrations to another framework or to remove the actual one. It can reduce significantly the dependency on the container what ease the testing too.

Regarding this practices:

• Dependency Injection: Field Injection vs Constructor Injection?

When to use DI containers

My answer is going to be biased by own experience which is mainly in favour of DI containers (as I commented, I'm heavily focused on productivity, so I have never had the need of pure DI. Quite the opposite).

I think you will find interesting Mark Seeman's article about this subject, which also answers the question how to implement pure DI?.

Finally, if we were speaking of Java, I would consider first taking a look to the JSR330 - Dependency Injection.

Summarising

Benefits:

• Cost-cutting and time-saving. Productivity.
• A smaller number of components.
• The code becomes simpler and cleaner.

Drawbacks:

• DI is delegated to 3rd party libs. We should be aware of their trade-offs, strengths and weakness.
• Learning curve.
• They quickly make you forget some good habits.
• Increase of the project's dependencies (more libs)
• Containers based on reflection require more resources (memory). This is important if we are constrained by the resources.

Differences with pure DI:

• Less code and more configuration files or annotations.

Answer 2

In my experience, a dependency injection framework leads to a number of issues. Some of the issues will depend on the framework and tooling. There might be practices that mitigate the issues. But these are the issues that I've hit.

Non-global objects

In some cases, you want to inject a global object: an object which will have only one instance in your running application. This might be a MarkdownToHtmlRendererer, a DatabaseConnectionPool, the address for your api server, etc. For these cases, dependency injection frameworks work very simply, you just add the needed dependency to your constructor and you've got it.

But what about objects that aren't global? What if you need the user for the current request? What if you need the currently active database transaction? What if you need the HTML element corresponding to the div which contains a form in which is a text box which has just fired an event?

The solution I've seen employed by DI frameworks is hierarchical injectors. But this makes the injection model more complicated. It becomes harder to figure out just what will get injected from what layer of the hierarchy. It becomes difficult to tell whether a given object will exist per-application, per-user, per-request, etc. You can no longer just add your dependencies and have it work.

Libraries

Often you will want to have a library of reusable code. This will also include the instructions for how to construct objects from that code. If you use a dependency injection framework, this will typically include binding rules. If you want to use the library, you add their binding rules to yours.

However, various problems can result. You may end up with the same class bound to different implementations. The library may expect certain bindings to exist. The library may override some default bindings causing your code to do strange thing. Your code may override some default binding causing the library code to do strange things.

Hidden Complexity

When you manually write factories, you have a sense of how the dependencies of the application fit together. When you use a dependency injection framework, you don't see this. Instead, objects tend to grow more and more dependencies until sooner or later everything depends on pretty much everything.

IDE Support

Your IDE will probably not understanding the dependency injection framework. With manual factories, you can find all the callers of a constructor to figure out all the places that the object might get constructed. But it won't find the calls generated by the DI framework.

Conclusion

What do we get from a dependency injection framework? We get to avoid some simple-minded boilerplate needed to instantiate objects. I'm all for eliminating simple-minded boilerplate. However, maintaining simple minded boilerplate is easy. If we are going to replace that boilerplate, we should insist on replacing it with something easier. Because of the various issues I've discussed above, I don't think frameworks (at least as they stand) fit the bill.

Answer 3

Does Java + dependency injection = framework required?

No.

What does a DI framework buy me?

Object construction happening in a language that isn't Java.

---

If factory methods are good enough for your needs you can do DI in java completely framework free in 100% authentic pojo java. If your needs go beyond that you have other options.

The Gang of Four design patterns accomplish many great things but have always had weaknesses when it came to the creational patterns. Java itself has some weaknesses here. DI frameworks really help with this creational weakness more than they do with the actual injections. You already know how to do that without them. How much good they will do you depends on how much help you need with object construction.

There are many creational patterns that came out after the Gang of Four. The Josh Bloch builder is a wonderful hack around java's lack of named parameters. Beyond that are iDSL builders that offer a lot of flexibility. But each of these represent significant work and boilerplate.

Frameworks can save you from some of this tedium. They are not without drawbacks. If you are not careful you can find yourself dependent on the framework. Try switching frameworks after using one and see for yourself. Even if you somehow keep the xml or annotations generic you can end up supporting what are essentially two languages that you have to mention side by side when you advertize programming jobs.

Before you become too enamored with the power of DI frameworks take some time and investigate other frameworks that give you capabilities that you may otherwise might think you need a DI framework for. Many have branched out beyond simple DI. Consider: Lombok, AspectJ, and slf4J. Each overlaps with some DI frameworks but each works fine on their own.

If testing is really the driving force behind this please look into: jUnit (any xUnit really) and Mockito (any mock really) before you start thinking a DI framework should take over your life.

You can do what you like, but for serious work I prefer a well populated tool box to a Swiss army knife. Wish it was easier to draw these lines but some have worked hard to blur them. Nothing wrong with that but it can make these choices challenging.

Answer 4

Creating classes and assigning them dependencies is part of the modeling process, the fun parts. It's the reason why most of programmers enjoy programming.

Deciding, which implementation will be used and how classes are constructed is a thing which will have to be implemented somehow and is part of application configuration.

Manually writing factories is a tedious work. DI frameworks make it easier by automatically resolving dependencies which may be resolved and requiring configuration for those which may not.

Using modern IDEs allows you to navigate through methods and their usages. Having manually written factories is quite good, because you can simply highlight a class' constructor, show its usages, and it will show you all the places where and how the specific class is being constructed.

But even with DI framework, you can have a central place, such as object graph construction configuration (OGCC from now on), and if a class depends on ambiguous dependencies, you can simply look into OGCC and see how a specific class is being constructed right there.

You could object, that you personally think being able to see the usages of a specific constructor is a great plus. I would say what comes out better to you is not only subjective, but comes mostly from personal experience.

If you had always worked on projects which relied on DI frameworks, you would really know only that and when you wanted to see a configuration of a class, you would always look into OGCC and wouldn't even try to see how the constructors are used, because you would know the dependencies are all wired up automatically anyway.

Naturally, DI frameworks cannot be used for everything and every now and then you will have to write a factory method or two. A very common case is constructing a dependency during iteration over a collection, where each iteration supplies a different flag which should produce a different implementation of an otherwise common interface.

In the end it will most likely all come down to what your preferences are and what you are willing to sacrifice (either time writing factories or transparency).

---

Personal experience (warning: subjective)

Speaking as a PHP developer, although I like the idea behind DI frameworks, I have only ever used them once. That was when a team I was working with was supposed to deploy an application very quickly and we couldn't lose time writing factories. So we simply picked up a DI framework, configured it, and it worked, somehow.

For most projects I like to have the factories manually written because I don't like the black magic happening within DI frameworks. I was the one responsible for modeling a class and its dependencies. I was the one deciding why the design looks the way it does. So I'll be the one who properly constructs the class (even if the class takes hard dependencies, such as concrete classes instead of interfaces).

Answer 5

Yes, when working in Java, I would recommend a DI framework. There are a few reasons for this:

• Java has several extremely good DI packages that offer automated dependency injection and also usually come packaged with additional capabilities that are harder to write manually than simple DI (eg scoped dependencies that allow automatic connection between scopes by generating code to look up what scope should be in use an d finding the correct version of the dependency for that scope - so for instance application scoped objects can refer to request scoped ones).

• java annotations are extremely useful and provide an excellent way of configuring dependencies

• java object construction is overly verbose compared to what you're used to in python; using a framework here saves more work than it would in a dynamic language.

• java DI frameworks can do useful things like automatically generating proxies and decorators which are more work in Java than a dynamic language.

Answer 6

Personally I don't use DI-containers and don't like them. I have couple of more reasons for that.

Usually it's a static dependency. So it's just a service locator with all its drawbacks. Then, due to the nature of static dependencies, they are hidden. You don't need to deal with them, they are somehow already there, and it's dangerous, because you cease to control them.

It breaks OOP principles, such as cohesion and David West's Lego-brick object metaphor.

So building the whole object as close as possible to the program's entry point is the way to go.

Answer 7

If your project is small enought and you do not have much experience with the DI-Framework i would recommond to not using the framework and do di manually.

Reason: I once worked in a project that used two libraries that had direct dependencies to different di frameworks. they both had frameworkspecific code like di-give-me-an-instance-of-XYZ. As far as i know you can only have one active di-framework implementation at a time.

with code like this you can do more harm than benefit.

If you have more experience you would probably abstract away the di-framwork by an interface (factory or servicelocator) so this problem will not exist any more and the di framework will do more benefit that harm.

Answer 8

As you already have noticed: Depending on the language you use, there are different points of views, diffenrent takes on how to deal with similar problems.

Regarding to dependency injection, it comes down to this: dependency injection is, as the term says, nothing more than putting the dependencies one object needs into that object - contrasting the other way: letting the object itself instatiate instances of objects it depends on. You decouple object creation and object consumption for the win of more flexibility.

If your design is well layed out, you usually have few classes with many dependencies, therefore the wiring up of dependencies - either by hand or by a framework - should be relatively easy and the amount of boilerplate to write the tests should be easy managable.

That said, there is no need for a DI-framework.

But why do you want to use a framework nevertheless?

I) Avoid boilerplate code

If your project gets a size, where you feel the pain of writing factories (and instatiations) again and again, you should use a DI-framework

II) Declacrative approach to programming

When Java was once programming with XML it is now: sprinkling fairydust with annotations and the magic happens.

But seriously: I see a clear upside to this. You clearly communicate intent with saying what is needed instead of where to find it and how to build it.

---

tl;dr

DI frameworks don't make your codebase magically better but it helps making good looking code looking really crisp. Use it, when you feel you need it. At a certain point in your project, it'll save you time and prevent nausea.

Answer 9

Yes. You should probably read Mark Seemann's book titled "Dependency Injection". He outlines some good practices. Based on some of what you've said, you might benefit from. You should aim to have one composition root or one composition root per unit of work (e.g., web request). I like his way of thinking that any object you create is considered a dependency (as is any parameter to a method/constructor) so you should really be careful of where and how you create objects. A framework will help you keep these concepts clear. If you read Mark's book you'll find more than just the answer to your question.