As much as framework authors would love for their work to be a silver bullet, solving all the world's DI problems, this is sadly not the case; there are some costs associated with adopting a framework and reasons that you may choose not to use one. These include the following.
Only supports constructor injection—You may have noticed in this chapter that all of the examples used constructor injection. This is not by accident. Wire, like many frameworks, only supports constructor injection. We did not have to remove our use of other DI methods, but the framework is unable to assist us with it.
Adoption can be costly—As you saw in the previous section, the end result of adopting a framework can be rather good, but our service is small and we were already using DI. If either of these things were not true, we would have been...