Overriding Default Key Mapping Startegy

Mar 28, 2011 at 10:20 AM

My system has unity configuration file to map each type to its implementation.

I don't want to manage every type in this file, so i exclude the default implementations, which i consider as: "Foo" for the type "IFoo", from the configuration.

I use a Unity extension to add a key mapping strategy for the default implementation and only the other implementations need to be in the file.

Things get complicated when i want to allow the default implementation be in the file, so the resolve process will first check the file and only if there's no default implementation there, it will be created by the new startegy.

It doesn't work for me since i added my DefaultBuildKeyMappingStrategy but the the default key mapping startegy for Unity - BuildKeyMappingStrategy - still exists and it is mapping the default implementation if it is in the configuration.

How can i remove it or check if a mapping had already been added from my startegy?

Thanks,

Danny

Mar 29, 2011 at 7:18 AM
Edited Mar 29, 2011 at 7:22 AM

Sorry, but I'm actually confused with your statement, do you want your strategy to override the type mapping in the config or is it the other way around?

 

Sarah Urmeneta
Global Technologies and Solutions
Avanade, Inc.
entlib.support@avanade.com

Mar 29, 2011 at 10:03 AM

I want the type to be created from configuration if it's there, but if it's not - i want the strategy to create it (assuming a class with the same name (without preceding "I") exists).

Another thing:

After the strategy has changed the build key for the resolve process, how do i add it as a persistent mapping?

Do i need to create a new BuildKeyMappingPolicy for that?

Mar 30, 2011 at 5:09 AM
Edited Apr 1, 2011 at 4:29 AM

There are two ways you could accomplish what you want.  First,do reflection to register the types ahead rather than figure things out during the actual resolving of the type.  You would do the logic of the registration in the Initialize method of a custom unity extension.  In that way, configuration type mapping will override whatever you registered in the custom extension as long as you added the extension first before loading the container from the config or if you added the extension in the config file rather than adding it programmatically.

The other way is the way you're currently trying to figure out right now.  You could check if there's an existing type mapping for the current type that is to be resolved using this code:

var policy = context.Policies.Get<IBuildKeyMappingPolicy>(context.OriginalBuildKey);

If the variable policy is null, it means no type mapping for the current type exists yet.  To add one and persist it, you could add a IBuildKeyMappingPolicy in the context.PersistentPolicies object:

 
if(policy == null)
{
      context.PersistentPolicies.Set(new BuildKeyMappingPolicy(new NamedTypeBuildKey(mapToType)), new NamedTypeBuildKey(context.BuildKey.Type));
}

where mapToType variable is the type of the concrete implementation of the interface. 

You may want to consider the first approach since it doesn't add a logic everytime the Resolve method executes.

 

Sarah Urmeneta
Global Technologies and Solutions
Avanade, Inc.
entlib.support@avanade.com

Mar 30, 2011 at 9:14 AM

Thank you very much for that. I used the RegisterType(from, to) method to add the mapping policy to the current container during the resolve process.

I didn't use the registration at the initialization stage since i don't have a small predifined list of types to resolve but rather a large scale system with numerous assemblies.