Do dependency injection frameworks pose a dependency risk?

Question

I have been refactoring an existing system to use dependency injection, and that work has been going smoothly.

After a while I noticed that a large number of in-house libraries became dependent upon the DI framework I used. As a result the entire project now depends upon this third-party framework.

I saw an irony in decoupling all the dependencies by making them dependent upon a shared library.

My first reaction was to create a wrapper library around the dependency framework. Therefore, I could replace this framework if needed. After estimating the work involved I realized that the resulting API would be to similar to the existing framework, and therefore make replacing it more difficult. So I abandoned the idea.

My concern is that the DI framework I'm using becomes obsolete or needs replacing.

Does there exist a development pattern when working with DI that reduces the coupling between a project and the DI framework?

Answer 1

You are fully correct - using a DI framework will most probably make your code dependent from that thing. Actually, that is too surprising, since this is typically true for every other framework or foundation library, especially when that lib supports your project with some generic features used everwhere in your code. For example, when you decide to use a certain UI framework or Web framework, this decision is hard to change afterwards as soon as you have build a certain amount of code based on that library. When you decide to use a specific (maybe non-standard) String class, you cannot easily change that decision later. Such a decision is an architectural one, it is like choosing a certain programming language and try to change that decision after you have written >100K lines of code.

Having all of your code depend on a certain framework might not be a problem as long as it does what you expect from it, and as long as it is properly maintained. But it can become an issue if that's not the case. There are some strategies how to deal with that situation:

• choose a framework from a vendor you have faith in that he can deliver you updates and new releases for several years from now

• choose an open source framework which has few enough lines of code (and a proper license), so you can do any maintenance on your own, given the vendor vanishes from the market

• write your own framework

• live with the situation as long as the vendor is available, and when he really vanishes, choose a different framework and try to create an adapter which emulates the old framework using the new

The idea of creating a wrapper library beforehand is not new at all, but I have seldom seen that working, since you would have to make assumptions for a future situation for which you don't know if or when it will hit you, and what the "new" framework will look like. On the other hand, some years ago we successfully exchanged a complete UI framework in a C++ project with ~120K of lines of code by applying the adapter strategy I mentioned above.

Answer 2

Ordinary constructor injection doesn't require a framework at all. The only thing you lose out on is the ability to centralize your dependencies in a configuration file.

DI containers are an "enterprise software" pattern, used when the object graph is very large and complex. I suspect that 95% of applications do not require it.

Answer 3

I don't think DI frameworks can really become obsolete anytime soon. What should happen to make it obsolete?

• An invention of a new and smarter pattern maybe? However it should look like, it would require much bigger changes in the code.
• A change in the language maybe? Even worse.

I'd say that the current DI is mature enough and I'm not aware of much happening there. You haven't specify your language, so speaking of Guice, it's fairly non-obtrusive and works with standard Java annotations (also uses their own for things not standardized, but you rarely need it). It's open sourced, widely used, and Apache licensed. What could be the problem?

I'm pretty sure that changing the DI framework would be orders of magnitude easier than changing any other library (e.g., a UI change means much more work).