In my opinion it just inverses the inversion and could make new users (including myself) make incorrect assumptions about using IoC containers.
It can be used for the Service Locator (anti-)pattern of course, but it doesn’t sound like a strong reason to me (can be a separate class in the end of the day).
There probably will be at least one call to get the root object to start the program, but it could be named and designed (signature and contract) accordingly to avoid calling it for more than one reason.
I am more interested in single-point of entry “classic” apps rather than server-side web apps.
4
DI containers are tools and tools can be used in many ways, which may be correct or incorrect. An axe is designed to chop wood, but it can also chop the neighbor’s tree cause its leaves are falling on axe owner’s lawn. The axe doesn’t know how it’s being used. But it still needs to cut.
Same goes for DI containers. Their creators don’t know all the possible scenarios of how their tool will be used. It’s easier for them to tell you how to use it properly, rather than prevent you from doing the things deemed as incorrect uses of the tool. Resolve is the feature that does the cutting, in this case. If you choose to misuse it, it’s your choice.
Even if service locator pattern is an anti pattern it sometimes useful. Say you are using event sourcing where you can have multiple event handlers for an event. Say
IHandleEvent<T>
Multiple classes can handle the same event. When the user logs in you are tasked with instantiating all classes that implement. Also you have a large number of events in your system and T is not known until runtime.
IHandleEvent<UserLoggedIn>
In this case you can ask your ioc container for all implementations of the interface.
Alternatively you can duplicate lots of the functionality in an ioc container. Obviously the first approach is easiest to implement.
Sometimes advanced scenarios of the tools are useful.
9