PolicyInjection.Create() with VirtualMethodInterceptor

Mar 25, 2012 at 6:35 PM

Hello,
We are using EntLib 5.0, and calling the PolicyInjection.Create method in order to instantiate objects, like this:

var dal = PolicyInjection.Create<CoreDataAccess, ICoreDataAccess>();

However it seems that the returned type is a wrapper.

Instead, I would like to be given a derived type instance, using the VirtualMethodInterceptor.
Is there any way to make Policy Injection perform this?

Thanks,
Dor.

Mar 25, 2012 at 6:46 PM

Alternatively, calling Unity.Resolve() to perform the instantiating is also OK.
However, I need it to read the policy injection policy from the policy injection configSection, which is configurable by the EntLib tool.

Thanks,
Dor. 

Mar 26, 2012 at 1:49 AM

One of the limitations of the Policy Injection Application Block is that interception is done using a TransparentProxyInterceptor.  One option is to switch to use Unity interception where you can control the interception.  The problem with that method is that the Unity approach does not use the <policyInjection> Enterprise Library configuration information for setting up interception which goes against your second requirement.

 It might be possible to write some code that translates the Enterprise Library Policy Injection configuration to Unity (either at runtime or compile time) and then use Unity interception.  

If you truly cannot modify the configuration then this might be an instance where modifying Enterprise Library is a good approach.  The change itself looks very small: just change new TransparentProxyInterceptor() in PolicyInjector.cs to new VirtualMethodInterceptor().  Of course, this assumes that changing the interceptor type won't break any other existing code that you have written.

--
Randy Levy
Enterprise Library support engineer
entlib.support@live.com 

Mar 26, 2012 at 10:13 AM

Hi Randy,
Thanks for the quick reply. :)

Regarding translation of policies: Do they have the same schema, which I can just load to Unity, or do I have to manually transform it?

Changing the EntLib source code does seem like the a simple solution, yet I'm afraid that this kind of modification will be forgotten when we upgrade to a newer version.

Thanks,
Dor. 

Mar 27, 2012 at 1:20 AM
Edited Mar 27, 2012 at 1:23 AM

Unfortunately, the schemas are not the same.  They are similar in some respects.  E.g. Policy Injection:

    <policyInjection>
        <policies>
            <add name="Policy">
                <matchingRules>
                    <add type="Microsoft.Practices.EnterpriseLibrary.PolicyInjection.MatchingRules.NamespaceMatchingRule, Microsoft.Practices.EnterpriseLibrary.PolicyInjection, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
                        name="Namespace Matching Rule">
                        <matches>
                            <add match="Match" />
                        </matches>
                    </add>
                </matchingRules>
                <handlers>
                    <add type="Microsoft.Practices.EnterpriseLibrary.Logging.PolicyInjection.LogCallHandler, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
                        name="Logging Call Handler" />
                </handlers>
            </add>
        </policies>
    </policyInjection>

 vs. Unity Interception

      <interception>

        <policy name="Policy">
          <matchingRule name="Match" type="UnityCallHandlerConfig.AnyMatchRules, UnityCallHandlerConfig" />
          <callHandler name="MyInterceptor" type="UnityCallHandlerConfig.MyInterceptor, UnityCallHandlerConfig"/>
        </policy>
        
      </interception>

      <register type="UnityCallHandlerConfig.IInterceptable, UnityCallHandlerConfig" mapTo="UnityCallHandlerConfig.BizClass, UnityCallHandlerConfig">
        <interceptor type="TransparentProxyInterceptor"/>
        <policyInjection />
      </register>
> Changing the EntLib source code does seem like the a simple solution, yet I'm afraid that this kind of modification will be forgotten when we upgrade to a newer version.

I agree with you -- it is one of the major negatives of modifying the Enterprise Library. Just to lay out the options I can think of:
  • Convert to use Unity interception instead of Policy Injection.
  • Modify the Policy Injection Application Block to use VirtualMethodInterceptor.
  • Write a translator (perhaps as a UnityContainerExtension) to read the PIAB configuration register the equivalent setup in Unity and use Unity for resolving objects. 

--
Randy Levy
Enterprise Library support engineer
entlib.support@live.com