I’m using castle windsor for a pet-project I’m working on. I’m starting to notice that I need to call the IoC container in different places in my code to create new objects. This dependency on the container makes my code harder to maintain.
There are two solutions I’ve used to solve this problem
I tried to create abstract factories as wrappers around the container that I could inject into parts of my application that need to create objects. This works but has some drawbacks because castle has a hard time injecting it’s own container as a dependency. So I have to do that by hand, this kind of defeats the whole purpose of the IoC container.
I have used the main applicationcontroller class to wrap the IoC container and work as a central factory/repository. This was quite succesfull but this class is getting too big and acts like a central god-object, almost every other objects has a reference to it.
Both solutions sort of work but both have their drawbacks. So I’m curious if other people had the same problem and have found better solutions.
edit The problem isn’t for object A that depends on object B. Here I usually just use constructor injection and everything works. Sometimes I have objects of type A that need to create a variable number of other objects of type B during their lifetime. I’m not sure how to do this.
@Blair Conrad: The maintenance issues are not severe until now. I had some classes depend on the container object calling container.Resolve<>. And I don’t want to have my code depending on what I think is infrastructure. I’m still trying things out so I noticed I had to change a lot of code when switching from ninject to castle for this project.
@flowers: Hmm. I like your fists solution. It combines the things that work from both solutions I’ve tried. I think I was still thinking too much in objects and not enough in interfaces/responsibilities. I tried purpose built factories but I would like to have them use the container behind the scenes to create the objects and I havn’t found out how I can DI the container into objects in a clean way.
The main benefit of Dependency Injection, at least in my applications, is the ability to write code that is context agnostic. From that perspective, your second solution seems like it really subverts the benefit DI could be giving you. If the ‘god object’ exposes different interfaces to each class that references it, it might not be too evil. But if you went that far I don’t see why you don’t take it all the way to the hoop.
Example: Your God object has a getFoo() method and a getBar() method. Object A needs a Foo, object B needs a Bar. If A just needs one Foo, Foo should be injected directly into A and A should not be aware of God at all. But if A needs to keep creating Foos, giving A a reference to God is pretty much inevitable. But you can protect yourself from the damage done by passing God around by narrowing the type of the reference to God. If you make God implement FooFactory and give A a reference to the FooFactory implemented by God, you can still write the code in A in a context-neutral way. That improves the opportunities for code reuse, and it increases your confidence that a change to God will not cause unexpected side-effects. For example, you can be certain when removing getBar() from God that class A won’t break.
BUT … if you’re going to have all those interfaces anyway, you’re probably better off writing purpose-built factory classes and wiring all your objects together, factories included, within the container, rather than wrapping the container at all. The container can still configure the factories.