Unity Interception vs. PolicyInjection

Feb 2, 2009 at 10:51 AM

It would seem as though the combination of interception within unity has some fundamental changes that really makes it no viable for all but the simplest of Call Handlers including custom. Let me explain, prior to adding interception support to unity you would have to include a policy injection section configuration element within your application configuration, adding the relevant matching rules and handlers. And this is where the problem occurs within the interception policy world you can add custom configuration denoted by the ConfigurationElementType(typeof(...)) attribute. This works really well for complex call handlers:<o:p></o:p>

<o:p> </o:p>

       <handlers>

          <add type="ATO.EN.ApplicationServices.Policies.Messages.MessageLookupPolicyHandler, ATO.EN.ApplicationServices"

               lookupProviderName="MessageLookupProvider" order="0" name="Message Lookup Handling"/>

          <add type="ATO.EN.ApplicationServices.Policies.Caching.CachingPolicyHandler, ATO.EN.ApplicationServices"

            cacheManagerInstanceName="Cache Manager" cacheItemPriority="<st1:place w:st="on">Normal</st1:place>" order="0" name="Caching Policy">

            <cacheItemExpirationsData><o:p></o:p>

              <clear /><o:p></o:p>

              <add cacheItemExpirationDataType="ATO.EN.ApplicationServices.Policies.Caching.Configuration.AbsoluteTimeExpirationData, ATO.EN.ApplicationServices"<o:p></o:p>

                absoluteTime="2009-10-23 11:47pm" name="Absolute Time Expiration" /><o:p></o:p>

            </cacheItemExpirationsData><o:p></o:p>

          </add>

        </handlers>

 

As we can see the caching call handler has some complex configuration requirements. Within the new world I’m able to define interception within the unity container (within configuration) via the extensionConfig element. It would appear I’m limited to the same elements as the usual unity typeconfig element within injection tag. In other words constructor, property and method elements.<o:p></o:p>

<o:p> </o:p>

Is this the expected coding style going forward or is there any way in which the old configuration support can be utilized. It would be really cumbersome to not be able to provide custom configuration.<o:p></o:p>

Feb 2, 2009 at 7:39 PM
Everything in the custom config ends up being either constructor parameters or property values on the call handler, so you don't actually lose any capabilities. You just need to specify the information in a different way. Having said that, the old config is a lot less verbose and you have the advantage of configuration tool support.

Luckily, it's pretty easy to use the older PIAB config with the Unity interception mechanism. I've got some code around here I'll try to dig up that does it. Basically, you get a PolicyInjectionSettings object from your configuration source, then use it to configure your existing container. Pretty straightforward, I'll post the code later.

Feb 2, 2009 at 10:13 PM
Found it. This extension method:

        public static Interception ApplyPIABConfiguration(this Interception containerExtension)
        {
            IConfigurationSource configSource = ConfigurationSourceFactory.Create();
            var settings =
                (PolicyInjectionSettings) configSource.GetSection(PolicyInjectionSettings.SectionName);

            if(settings != null)
            {
                settings.ConfigureContainer(containerExtension.Container, configSource);
            }

            return containerExtension;
        }

can be used like this:

container.Configure<Interception>().ApplyPIABConfiguration();

and it'll read the PIAB config out of your standard configuration source and suck it into the container.



Feb 3, 2009 at 5:07 AM
Would another alternate solution be to use a type with a custom type config rather than relying on the default TypeInjectionElemen? if so what would I need to do to implement it I've not seen any examples of custom type config.