Antipatterns of use of IoC containers. Why are IoC containers so complex and so fancy to use?

Question

I'm seriously starting to think that using the IoC container provokes the creation of overridden solutions (at least it provokes me to use various unnecessary functions :).

This is the time to sync my IoC list with the community.

My short experience says that to launch one of the applications at startup, it’s enough to enable the Resolve method to enable some infrastructure singleton and initiate a “transition factory” with them, which could create new “small life-time grain factories”. Even making these factories safe for threads (for example, creating one instance per thread) is so easy to achieve by adding 10 lines of code to the factory ... Nevertheless, these factories are much simpler than "integrating the library with the IoC tool." Intercept? Just create your own wrappers ... Life time managers / dependency strategies / parent containers? Call Resolve only once in the bootstrapper and you won’t think about it.

Could you help me understand why the developers call Resolve several times at different levels of the application (passing the container or passing the delegate to the container), and then there is a lot to think about? I'm really worried I'm missing something.

Answer 1

When it was not clear to me how to use the IoC container, I decided to stop using it because I thought it was just overuse over a simple dependency injection.

True, although even without IoC you can get into cases of excessive injection. Some time ago, I read several posts from the author of ninject, who opened my mind.

As you already know, an injector should only be used inside the context root. However, in order to avoid excessive injections, I decided to introduce an exception to the rule for the introduced factories.

In my framework, factories (and only factories) can use an injector container. Plants are bound in a container at the root of the context and therefore can be entered. Factories become real dependencies and are used to create new objects inside other objects, using an injector container to facilitate dependency injection.

Answer 2

Read it

Clearly, something is wrong. The new library should not bring additional complex code.

Answer 3

Some types of IoC are anti-patterns or may be in some cases. For example, an antivirus service locator tool . But if you use constructor injection at the beginning of your application - and only there - then this should not lead to an anti-pattern.

Including the DI container interface in a class is a misuse of constructor injection. If the DI is not part of the business logic of your class, it should not know or depend on the DI container and should not depend on IKitchen. This is normal if you insert your DI container into some kind of helper or service that works in conjunction with the dependency injection container, since it is designed to work with or around the container. The examples in the links you give are misuse of IoC. This does not mean that IoC as a whole is an anti-pattern.

I think the right question is: “Can a constructor injector be an anti-pattern?”. Until now, I have never encountered a situation or seen any example of where it was, so I would say no until I came across such a situation.

Answer 4

I found someone who could understand me :)

Constructor over-injection anti-pattern

Answer 5

Another antipattern in my eyes pushes the initialization of the container “deeper”, and then the actual load.

For example, Unity and WCF Recommendations

The bootstrapper in the wcf app is the service constructor, and then just put the container initialization in the constructor. I don’t understand the reasons to recommend wcf sevice behaiviors and host cvome sevice host factory programming: if you want to have the boot bot “IoC container free” - this is absurd, if you need a service contract “without IoC container” implementation - just create a second implementation service contract without using an IoC container. "