Property Injection using DependencyAttribute and Policies

Topics: ObjectBuilder
Jun 13, 2007 at 1:48 AM
My question concerns property injection. How do you go about injecting a basic instance of an object into various types? For instance, say I want to create an IWidget object as a single instance and would like to inject it into any built-up objects with an IWidget property. I've attempted using the DependencyAttribute and creating a PropertySetterPolicy, but this only appears to work if you specify the exact type which will receive the injection. I would like to inject the IWidget into any object without having to know which ones will contain the attribute. Are policies not the correct avenue here?

This leads me into a more general question I have about Policies. It appears that policies only match against specific types and not against subtypes. If this is the case, why was ObjectBuilder designed this way? It would seem you would want to be able to say "This policy applies to all automobiles" and expect it to be applied to Chevys, Toyotas, and Fords. Thanks.
Jun 13, 2007 at 10:16 PM
I think you have it backward.

If an object has a property that is for ICar, then it can take a Ford or a Chevy or a Toyota. However, if it asks for a Toyota, it's clearly not going to be happy with a Ford.

So, the object property needs to ask for ICar, so that we know it's okay with any car.

When you're setting the properties, type mapping is used to say "Anybody who asks for an ICar gets a Ford today".

As to your general question, the reason it's the way it is is... because that's the way it is. No more than that. Someone could easily write or change the property setter strategy so that it not only looked for policies based on the exact type, but also all the types in its inheritance chain, as well as all of its implemented interfaces. There's nothing in the core of ObjectBuilder that prevents such a strategy from being written.
Jun 14, 2007 at 3:55 PM
You misunderstood the question, but that's alright as I was able to determine how this is done by examining the code and searching around for examples. My question concerned how to inject an instance of an object into various types, not how to inject various types into an instance of an object.

The problem I was trying to solve was how to inject classes A, B, & C with an instance of IWidget without ObjectBuilder having to know specifically that A, B, & C existed. That is to say, I didn't want to have to configure separate policies for each type that might have the property injected as this would require having to modify the ObjectBuilder configuration code every time a new object wanted to receive the property. Looking at an extreme case of this approach reveals a clear violation of SoC.

Where I went astray was in thinking that the use of Policies was the way to address this, which lead me to question why I couldn't register a policy for any derivative of System.Object (i.e. "I want any object to be able to declare a dependency on IWidget.").

The solution is to add the dependency instance to the locator used by the ObjectBuilder. When the property is considered for injection, this dependency key will be searched for within the locator.

Concerning my question about how policies are applied, I guess that would have been best placed in a separate thread to avoid any confusion, but it was related to my approach so I asked here. My example was the case of an application which defined an interface ICar from which were derived a Ford, a Chevy, and a Toyota. Each of these instances might then want to declare a property to be injected such as an IRadio. Ignore the fact the IRadio might actually be an instance of Sony, Panasonic, or Toshiba. Logically, the problem you want to solve is to have any instance of ICar which has a property of IRadio injected with an instance of IRadio. Speaking conceptually, your policy would be to give each car the same radio. Given this requirement, one might be lead to think that they want to create a policy for ICar which would inject an IRadio when processed, but as I've discovered, Policies aren't applied to derived types.

Certainly I could modify the source to do this if I didn't want my solutions to be forward compatible with future versions of ObjectBuilder, but what I'm really interested in is the reasoning why it was designed this way. I doubt "just because" is the ultimate reason :) Certainly determining if each object is a derivative of each policy's type would add overhead, so perhaps this was the ultimate reason.


Jun 15, 2007 at 7:04 AM
Well, I can tell it was "just because", because I was one of the three people who designed it. :) Seriously, we never considered the use case of checking all the classes in the hierarchy simply because our usage never showed that as something we needed.

I'll give it some thought...