Dependency in the base class

Nov 1, 2008 at 1:49 PM
I have several cases that resemble the following diagram:
The problem is to resolve ComplexClass which depends on SubClass1 and SubClass2, with different implementations of ISomeInterface interface.
I had a crude solution to this based on child containers, and it involved extending unity with new attibutes. It didn't prove very useful.
Is there a correct way to do this?

Nov 3, 2008 at 2:53 PM
I don't see why you need to extend unity with this case. You can always register two implementations of an interface.  After registering Implementation1 and Implementation2 in the container, it can already resolve ComplexClass since you have registered the types necessary for creating SubClass1 and SubClass2.

- Sarah
Nov 3, 2008 at 7:10 PM
Edited Nov 3, 2008 at 7:15 PM
SubClass1 and SubClass2 can't have direct dependencies on the implementations (Implementation1 and Implementation2). They indirectly depend only on the ISomeInterface interface. Implementations provide different behavior in a way that does not affect what sub classes do by themseves. I want to preserve reusability of subclasses, ComplexCalss and BaseClass.
Here's the code (I guess diagram  might be confusing):

public class BaseClass
    public ISomeInterface Instance {get;set;}

public class SubClass1 : BaseClass

public class SubClass2 : BaseClass

public class ComplexClass
    public SubClass1 ComplexDependency1 {get;set;}
    public SubClass2 ComplexDependency2 {get;set;}

Nov 3, 2008 at 10:53 PM
This is pretty easy to do with the API, not so easy with attributes.

IUnityContainer container = new UnityContainer()
        new InjectionProperty<ISomeInterface>("Instance", typeof(Implementation1)),
        new InjectionProperty<ISomeInterface>("Instance", typeof(Implementation2));

Do that, and when it goes to inject the Instance property for SubClass1 it'll resolve an Implementation1, and when it injects SubClass2 it'll inject an Implementation2.

Nov 4, 2008 at 6:57 AM
Edited Nov 4, 2008 at 7:02 AM
Well, I had tried this way (read it somewhere in the discussions). It helps in a simple example, when you only have 2 subclasses.
In the real world code I actually have about 20 and a lot more classes like ComplexClass which use them. So it is quite difficult to have to declare InjectionProperty for them all, besides what is the point of having Unity if I have to manually assign dependencies.
What I want is to find some way to group the classes which need specific implementation, like in a child container.
Nov 4, 2008 at 7:25 AM
As you've defined it, you're pretty much stuck with defining the properties manually. Unity (as with most DI containers) is very much based around the current type you're building up.

If you can change the code at all, the easiest thing would probably be to add constructors to SubClass1 and SubClass2 - then you'd have a place to define specifically which instance you really want based on the type.

You might want to consider another DI framework, Ninject. Ninject (besides having a very cool web site) supports something the author calls contextual binding, which lets you vary what gets injected based on the path through the object graph taken to get there. It might suit your requirements better.
Nov 4, 2008 at 11:55 AM
I didn't know that NInject had support for similar feature.
I'll definitely check it out, at least to see how it is implemented.