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?
Do dependency injection frameworks pose a dependency risk?
frameworks;dependency injection
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 nowchoose 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 marketwrite your own frameworklive 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 newThe 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.