1

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
  • A factory that produces instances of IoC-mapped types at runtime needs to be able to actually get those from IoC.
    – Wilbert
    Commented Sep 18, 2014 at 10:10
  • 1
    @Wilbert you could ask the IOC container for a factory. Like Func<MyType> in autofac. That way you don't need to directly depend on the IOC container in your factory. This requires of couse that the factory itself is instantiated from ioc. In a lot of cases an explicit factory is probably not needed if using an auto generated factory.
    – Esben Skov Pedersen
    Commented Sep 18, 2014 at 10:40
  • @EsbenSkovPedersen It doesn't matter if you get your IoC to generate your factory or if you make the factory yourself, in both cases it will contain a pointer to an IoC resolver (or some other IoC internal structure).
    – Wilbert
    Commented Sep 18, 2014 at 12:15
  • It matters, I think, that the number of classes with an specific IOC dependency is kept to a minimum. I would much rather see Func<T> than <insert IOC container of choice> in code. In theory the IOC container could be switched to another implementation without traversing the entire codebase.
    – Esben Skov Pedersen
    Commented Sep 18, 2014 at 12:20

2 Answers 2

Reset to default
1

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.

0

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
  • I will just automatically inject them into constructor via IEnumerable<IHandleEvent<T>> parameter (e.g. Autofac can do this AFAIK). No service locator is necessary as far as I can see.
    – Den
    Commented Sep 18, 2014 at 11:03
  • well T is not known until runtime so I'm pretty sure you can't do that.
    – Esben Skov Pedersen
    Commented Sep 18, 2014 at 11:17
  • @EsbenSkovPedersen containers can register open generic types and resolve them as needed at runtime
    – devnull
    Commented Sep 18, 2014 at 11:18
  • @devnull using open generic types also requires the type T to known at compile time which my example does not.
    – Esben Skov Pedersen
    Commented Sep 18, 2014 at 11:20
  • @EsbenSkovPedersen not really a problem in practice: stackoverflow.com/a/16758650/486561
    – Den
    Commented Sep 18, 2014 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.