The big hurdle is getting an inverted “Common Service Locator” happening. Just wrote about this (in perhaps too much detail) here: http://nblumhardt.com/2010/01/the-relationship-zoo/ – hope this makes some sense in your scenario, as frameworks like Agatha would be a primary consumer.

i already know about those features, and think they’re great

but i can’t use anything container-specific in Agatha since it needs to work with multiple containers…

i don’t know how carefully you read this post but i really don’t agree with Uncle Bob about the IOC thing _at all_. He advocates using manual DI and when things get a bit more complex, to switch to factories. Those factories that he suggests not only know about the dependencies of the classes they need to create, they’re also responsible for the registration of them. That’s pretty much the exact opposite of the kind of factory i showed in this post. And about not needing to represent factories as interfaces, i think we disagree on that as well. My post clearly shows that the factory does implement an interface and that i have it injected in the class that needs instances created by the factory. I even mention that this enables me to switch the implementation of both the factory, as well as the instances that are created. I can’t really think of any reason why i’d want to new up a factory instance… i’d have to have some kind of static hook into the factory to replace the type of the instance being created by the factory during tests. Which is another thing that i’m actively trying to avoid with DI.

If you still think that i agree with Uncle Bob or with you about this whole thing, i’d really like to see a more detailed explanation as to where you see the similarities in thoughts. Because i really don’t see them, quite the opposite in fact

Good point you have there. However, if you’re using the factory just as a facade for the container, than why bother hand coding it?
In Windsor all you need is the interface IAsyncRequestDispatcherFactory and you can have the container do the implementation for you.

The only change I’d make is to take the container as a constructor dependency rather that make it a global variable. Jeffrey did something similar in his example, where he introduced a (to my mind) unnecessary global variable to abstract out the container. I know it’s rare to want a second container in the same process, but making it an instance isn’t usually that hard.

Thank you,

Julian.

I have recently used the same approach as you in a project I am working on. Simply passing in the a dependency (a list of launch application buttons to show) did not fit as this would require either the container or the calling function (main) to assume responsibility for the contents. A factory made sense as this provided a single configuration point. The factory implementation simply called the container to resolve the specific button types and their dependencies.

It was my tests that drove me to that decision, either too much setup, too much direct access to the container.

The factory + container allows me to defer creation until I need it while simplifying my tests and the injected dependencies. I agree I can’t see a downside.

While calling the container directly is something that should be limited, it feels like a reasonable thing to do inside a factory class. Which after all that is its traditional role. Further more it has pushed the access to the container further to the edges of the design.

I’ve solved a similar problem with my own IoC container. Every service you register will have a sibling service being registered that will resolve to IServiceFactory{ServiceInterfaceType}. So, if you register a service like IEmployeeRepository, another service for IServiceFactory{IEmployeeRepository} will be registered for you, automatically. If you resolve for the service, the container will go about its business as usual, but if you resolve the factory service, you can then later on resolve the actual service from that factory service. If the service isn’t singleton, or container-scoped, you can also resolve it multiple times, for multiple instances.

Since this is handled by my container automatically, I can use the factory service in constructor calls to my other services, and have the factory automatically injected for me. This way I can easily flag in the code that my service depends on another service, but it either has lazy-resolution scenarios, or multiple-resolution scenarios, without having to just inject the whole container.