Unity 2.0 and DynamicMethodBuildPlanCreatorPolicy

Jan 20, 2010 at 5:55 PM

Hello,

I downloaded the Unity 2.0 solution and was very happy to find the Registrations property of the UnityContainer class. I also looked through the code of DynamicMethodBuildPlanCreatorPolicy and I have one question (because, as far as I see it, the answer is "no"):

is there a possibility to use injected properties and methods (via InjectionMember used in a mapping registration) with a IBuildPlanPolicy provided specifically for the registered mapping?

The case for which this behavior is needed, it's when there is a need of calling different constructors in different situations (the simple build plan created in one situation does not cover it). Of course writing a specific IConstructorSelectorPolicy and destroying IBuildPlanPolicy every time is a solution, but I'd consider it be the most low level hack.

Jan 21, 2010 at 5:45 AM

Well, the IBuildPlanPolicy can do whatever you want, but when you do that you end up completely taking over the build plan creation. The injection member objects just turn into policies which are available through the build context.

If I understand what you want, I'd suggest perhaps a different approach. The container is designed to support different constructors in different situations through named registrations. So what you could do is possibly include a smarter type mapping instead. Then you check the environment (or whatever it is you're doing) and then choose the name that matches up with what your current configuration needed is. That way the rest of injection just works.

 

Jan 21, 2010 at 11:49 AM
Edited Jan 21, 2010 at 4:39 PM

Thank you ctavares for your quick answer:)

I've never considered using named registrations in terms of resolving the issue I described, but it does make sense, iff there is a possibility to determine the conditions before resolving and use the right name. The same type can be registered with different names and different IConstructorSelectorPolicy policies. To narrow the topic, the need of deciding, how to construct an object, occurred, when I used disposable objects and there was a constructor to allow the objects' nesting. For instance:

public class A : IA, INested, IDisposable
{
	public A (INested otherObject)
	{
	// ...
	}
	public A (IOtherInterfaceWhichShouldBeUsedDuringTheMostOuterScope o)
	{
	// ...
	}
}

The need is to allow using container to run code analogical to the code below. The use of container would be very helpful, since there would be no passing the outer instances of A class, to the methods called inside the scope.

using (var a1 = new A (objectOfOtherInterfaceWhichShouldBeUsed))
{
	// ... do sth
	using (var a2 = new A (a1))
	{
		// ... do sth
	}
}

The code with use of Unity:
// use of not nested constructor
using (var a1 = Container.Resolve<IA>())
{
// ... do sth // use of nested constuctor using (var a2 = Container.Resolve<IA> ())
{
// ... do sth } }
I'm considering writing this kind of extension and trying to publish it in UnityContribution project.